Issue 6399. Don't fall back to 'dynamic' when variable has explicit type.

Issue 6399. Don't fall back to 'dynamic' when variable has explicit type.
http://code.google.com/p/dart/issues/detail?id=6399


R=brianwilkerson@google.com
BUG=

Committed: https://code.google.com/p/dart/source/detail?r=14306

[Brian Wilkerson, 2012-10-30 18:46:41]

https://codereview.chromium.org/11271041/diff/1/compiler/javatests/com/google...
File
compiler/javatests/com/google/dart/compiler/type/TypeAnalyzerCompilerTest.java
(right):

https://codereview.chromium.org/11271041/diff/1/compiler/javatests/com/google...
compiler/javatests/com/google/dart/compiler/type/TypeAnalyzerCompilerTest.java:2798:
assertInferredElementTypeString(testUnit, "v1", "B");
This looks wrong. I think v1 should be "A" and v4 should be "String". I agree
that "dynamic" was not the right answer, but I think you want to return the new
type when there is no superclass/subclass relationship between the two (at least
in the case of "is"; that might not be the right answer in all cases).

[scheglov, 2012-10-30 19:47:57]

https://codereview.chromium.org/11271041/diff/1/compiler/javatests/com/google...
File
compiler/javatests/com/google/dart/compiler/type/TypeAnalyzerCompilerTest.java
(right):

https://codereview.chromium.org/11271041/diff/1/compiler/javatests/com/google...
compiler/javatests/com/google/dart/compiler/type/TypeAnalyzerCompilerTest.java:2798:
assertInferredElementTypeString(testUnit, "v1", "B");
On 2012/10/30 18:46:41, Brian Wilkerson wrote:
> This looks wrong. I think v1 should be "A" and v4 should be "String". I agree
> that "dynamic" was not the right answer, but I think you want to return the
new
> type when there is no superclass/subclass relationship between the two (at
least
> in the case of "is"; that might not be the right answer in all cases).

1. There are no reason to replace in v1 case more specific type B with less
specific A.

2. If we will set type of v4 to String, then we generate warnings for accessing
members of B. We need actually union of these types.

[Brian Wilkerson, 2012-10-30 20:05:55]

LGTM

https://codereview.chromium.org/11271041/diff/1/compiler/javatests/com/google...
File
compiler/javatests/com/google/dart/compiler/type/TypeAnalyzerCompilerTest.java
(right):

https://codereview.chromium.org/11271041/diff/1/compiler/javatests/com/google...
compiler/javatests/com/google/dart/compiler/type/TypeAnalyzerCompilerTest.java:2798:
assertInferredElementTypeString(testUnit, "v1", "B");
> 1. There are no reason to replace in v1 case more specific type B with less
> specific A.

I see. I missed the subtype relationship. You're right.

> 2. If we will set type of v4 to String, then we generate warnings for
accessing
> members of B. We need actually union of these types.

Agreed, but in the absence of support for union types I still think String would
be the better type to infer because we know that the run-time type of v4 must be
String. Nevertheless, you can leave it if you want.