Confusing errors when there are types with the same name in different libraries

[Hixie]

import 'a.dart' as a;
import 'b.dart' as b;

void test(a.Foo foo) { }

void main() {
  b.Foo bar = new b.Foo();
  test(bar);
}

// a.dart and b.dart both look like this:
class Foo { }

Analyzer output:

Analyzing [test.dart]...
[error] Type check failed: bar (Foo) is not of type Foo (test.dart, line 8, col 8)
[warning] The argument type 'Foo (b.dart)' cannot be assigned to the parameter type 'Foo (a.dart)' (test.dart, line 8, col 8)
2 errors found.

Note how the error very confusing. The warning is great, though!

The checked-mode exception is bad too:

Unhandled exception:                                                                                                                                                                                            
type 'Foo' is not a subtype of type 'Foo' of 'foo'.                                                                                                                                                             
#0      test (test.dart:4:17)
#1      main (test.dart:8:3)
#2      _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:263)
#3      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:150)

[bwilkerson]

@jmesserly Is there any reason to have both an error and a warning for the same problem? I'm guessing not and that this is just part of the strong-mode integration work that isn't quite complete yet.

[jmesserly]

Yeah, one message is from CodeChecker and another is from ErrorVerifier.

I believe we can remove CodeChecker's type check messages, but we need to do double check that ErrorVerifier will produce a message every time CodeChecker would have. A nice bonus here is that ErrorVerifier's messages are friendlier.

@bwilkerson do you mind if I leave this unassigned? I'm not sure if I will work on it or @leafpetersen or @vsmenon.

[bwilkerson]

do you mind if I leave this unassigned?

Nope.

[munificent]

This is fixed by 2ef00b0. The redundant (and hard to understand) strong mode error is gone now and only the warning remains.

[Hixie]

Sweet! Thanks!