Analyzer 6.5 doesn't canonicalize element instances, breaking type checks

[simolus3]

I have tests that got broken by upgrading from analyzer version 6.4 to version 6.5. From a short investigation, the problem appears to be that I somehow ended up with two InterfaceTypes having equal, but not identical, elements. As InterfaceTypes are only equal if their elements are identical, this completely breaks type checks.

I unfortunately couldn't find a simple way to reproduce this yet (if having a simpler repro would help I'll investigate more time to reduce this), but this can be reproduced by running these tests:

git clone https://github.com/simolus3/drift.git
cd drift
dart pub global run melos bootstrap --scope drift_dev
cd drift_dev
dart test test/analysis/resolver/dart/custom_row_classes_test.dart

The tests are all failing due to this condition being hit. Here, I'm calling typeSystem.isAssignableTo(a, b) with types a and b that are both an int type. What's interesting is that expectedDartType.element == typeToCheck.element is true, but identical(expectedDartType.element, typeToCheck.element) is false! This causes the types to not be equal (despite describing the same thing) and the type system reporting that the types are incompatible.

One of the int types has been extracted from the type argument of a larger interface type, and the other int type is from TypeProvider.
I was under the impression that that's impossible to reach without seeing an InconsistentAnalysisException first (and it's a recent regression), so I figured I'd open an issue. I was unable to reproduce this with a simpler setup doing similar type checks unfortunately, but I can try looking some more if necessary.

[bwilkerson]

@scheglov

[scheglov]

Nothing prevents the client from asking a InterfaceType in one session, and then trying to work with a InterfaceType from another session. The client should not do this, but InconsistentAnalysisException will not help here.

[scheglov]

I added some hacks to the running system, so see _id of AnalysisSessionImpl instance.
And they are different.
So the client code is wrong.
Use the same session to get both types.

[simolus3]

Thank you for taking a look so quickly! And I have to apologize for filing this, from a deeper look it indeed turned out to be entirely my fault - I was setting up two analysis drivers by accident and then used results from the two drivers in the same places causing all kinds of trouble. I expected inconsistent analysis exceptions but that didn't happen because the sessions were both active in their respective drivers.

[bwilkerson]

Glad to hear that the issue has been resolved.