Dart analyzer interprets type hierarchy differently depending on symlink file structure

[ajrcarey]

Not sure if you folks like to receive issues submitted against dev sdk builds, but here we go...

SDK 1.21.0-dev.6.0 running on Ubuntu 16.10

Strong mode on

Consider the following type hierarchy:

abstract class A {

  void doA();

}

abstract class B<T> implements A {

  @override void doA();

  void alsoDoB();

}

class C {

  void doATypeThings(A a) {
    a.doA();
  }

}

class D implements B<D> {

  @override void doA() {}

  @override void alsoDoB() {}

}

class E {

  final D d;

  E(this.d);

}

class F {

  static final E _e = new E(new D());

  void doAllTheThings(C c) {
    c.doATypeThings(F._e.d); // <===== this is the line of interest
  }

}

Dart analyzer interprets this correctly and marks no errors. All good.

If I then move the definition of, e.g., class D out of this file and into another file that is then imported using an import 'package:...' statement, Dart analyzer reports the following error on the line marked with the comment above:

The argument type 'D' can't be assigned to the parameter type 'A'

I cannot escape the feeling that I am doing something wrong with my file structure that is causing this, but for the life of me I cannot see what. The error is not flagged when using SDKs 1.20.1 or 1.19.0.

[ajrcarey]

Here's another example of the same thing. Consider this type hierarchy:

//abstract class Measurement<T extends Measurement<T>>
abstract class Mm<T extends Mm<T>> {}

//abstract class Coordinate<M extends Measurement<M>, C extends Coordinate<M, C>>
abstract class Cc<M extends Mm<M>, C extends Cc<M, C>> {}

//abstract class Measurable<M extends Measurement<M>, C extends Coordinate<M, C>>
abstract class Ss<M extends Mm<M>, C extends Cc<M, C>> {}

//abstract class Rectangle<M extends Measurement<M>, C extends Coordinate<M, C>>
abstract class Rr<M extends Mm<M>, C extends Cc<M, C>>
implements Ss<M, C> {}

//class Vector<M extends Measurement<M>, C extends Coordinate<M, C>>
//implements ImmutableSerializable<Vector<M, C>>, Measurable<M, C>, Tuple<C, C> {
class Vv<M extends Mm<M>, C extends Cc<M, C>>
implements Ss<M, C> {}

As you can see, this one comes from a real-world example. Again, if everything is in the same file, Dart analyzer 1.21.0-dev.6.0 reports no problems.

Moving out class Ss into another file that is then imported back in raises problems with classes Rr and Vv, where the "implements Ss<M, C>" is marked in both cases with the errors:

'M' doesn't extend Mm<M>

'C' doesn't extend Cc<M, C>

(I should probably clarify that no parsing errors, or errors of any sort, are raised in the file containing the definition of Ss, and the definitions of Mm and Cc are available to Ss, again via an import statement.)

[bwilkerson]

Yes, we're happy to get reports based on dev builds. We're even happy to get reports about behavior on bleeding edge.

[ajrcarey]

After more testing, it seems the problem is related to symlinks. Where the source code for the project being analyzed is stored in a location referenced by a symlink, it appears that the Dart Analyzer can infer a filename in two ways: either the symlinked location, or the dereferenced location. This introduces a problem where the Analyzer cannot recognise the same class definition because it thinks it has found two different definitions (that happen to have the same name) at different locations.

For example, consider Class A defined in file a.dart in ~/src/my_project/a.dart, where the my_project directory is a symlink that points to (e.g.) ~/src/.all_my_many_projects/the_current_ones/my_project.

Dart Analyzer appears to consider ~/src/my_project/a.dart:Class A and ~/src/.all_my_many_projects/the_current_ones/my_project/a.dart:Class A to be two different things, even if they are explicitly defined to be part of a library using the library/part of statements. Consequently, any other class that attempts to reference A as a generic parameter can incur problems where A is recognised as a type parameter in one file but not as a compatible type parameter in another. For instance, a List<A> created in one function in one file might not be able to be passed to another function expecting a List<A> in another file, because the two files have two different ideas of what an A is. In my own project, with about 1000 dart files divided across about two dozen libraries, this does not happen consistently; some classes have been affected but not others, and I have not been able to determine any particular pattern.

Moving the project to a non-symlinked location and running Dart Analyzer again shows the expected behaviour: class A is recognised consistently, and any classes using A as a generic type parameter can correctly interact with one another without errors or warnings.

I know symlinks aren't a big thing on Windows, but for those of us on *nix systems, I think it's reasonable to expect Dart Analyzer to handle symlinks transparently. (Indeed, one might wonder why it is attempting to dereference symlinks at all?) The problem did not seem to occur in 1.20.1 and was definitely not in 1.19.

[bwilkerson]

Thanks for the extra info! That's definitely a bug. Internally, analyzer is suppose to be storing all file paths as absolute, normalized paths with symlinks resolved. It appears that there is someplace where a path isn't being correctly processed. Hopefully this will give us what we need in order to track down where that's happening.