confusing error: The argument type 'dart.core::String' can't be assigned to the parameter type 'dart.core::String'.

[mraleph]

Flutter users reporting bizarre errors from the compiler that confusingly appear and disappear (might be related to serialized incremental compiler state?)

Compiler message:
lib/main.dart:73:35: Error: The argument type 'dart.core::String' can't be assigned to the parameter type 'dart.core::String'.
Try changing the type of the parameter, or casting the argument to 'dart.core::String'.
            image: new AssetImage('s'),

I don't have a concrete reproduction for it - but I asked users that face it to send us their Dart source if possible.

I saw some reports that users resolved it by changing import scheme from relative to package-scheme imports

Any ideas what can be causing this @peter-ahe-google @kmillikin @jensjoha ? Maybe a bug in class hierarchy?

Maybe we could add some debugging information to CFE to dump more debugging information for this sort of error?

[zoechi]

After #33076 was fixed I have only seen this mentioned on Windows where upper-case wasn't used consistently when importing the same file.
@DanTup encountered this case a few times AFAIK with users.

[DanTup]

I've seen errors like this a few different ways (though all at analysis time):

1. Mixing of relative/package URIs
2. Mixed casing of import URIs
3. Analyzing code in the SDK repo using an older version of the SDK (I tend to use a recent nightly build when working in the SDK repo to avoid building locally frequently, but sometimes it fails like this and grabbing a more recent nightly fixes it)

I don't know if any of those are related to this, but maybe it helps. The error could definitely be improved for some of those cases (eg. where the strings are identical, or even when they differ only by case).

[lrhn]

The import-case issue explains other classes, but not String from dart:core. You cannot import dart:core with a different case. There must be something more fundamentally wrong if you have two versions of dart:core in your program.

[peter-ahe-google]

We are exploring a few ideas for how this situation could arise.

[peter-ahe-google]

We have a reproduction. More details will follow.

[jensjoha]

As @peter-ahe-google said we reproduced this.
We cannot say for sure this is the only way to do it, but it's at least the only way we can think of to reproduce it: IncrementalCompiler.fromComponent - so probably something happening as a consequence of a hot-reload failure.

Reproduction landing in CL (https://dart-review.googlesource.com/c/sdk/+/91228) soon.

This method (fromComponent) was written by and is used by the VM team and they should probably fix it. Either by not doing it at all (and instead serializing and loading from dill instead) or by somehow setting the incremental compiler up in such a way that duplicate data isn't read in.

[peter-ahe-google]

@aam let me know if you need to discuss this in detail. I think it may be a simple fix: Make sure that CompilerOptions.sdkSummary is null as well as CompilerOptions.inputSummaries and CompilerOptions.linkedDependencies are both empty when using IncrementalCompiler.fromComponent.

[aam]

Thanka @peter-ahe-google . I will take a look.

[aam]

It seems that we need to ensure that saved last known good state includes platform libraries, which doesn't currently - when we rebuild incremental compiler we reload platform libraries so references from saved state don't match to what is loaded for new incremental compiler.

@jensjoha @peter-ahe-google can you please take a look at concept https://dart-review.googlesource.com/c/sdk/+/91859 which basically adds list of platform libraries that incremental compiler can stash and use when reject has to rebuild compiler.

[a-siva]

is this issue resolved?

[aam]

is this issue resolved?

No, this is work in progress as this tracks proper implementation of vm reject request.

There are changes that @jensjoha implementing that will make fasta incremental compiler respect --omit-platform flag, then vm incremental compiler will be requesting incremental components with platform libraries, filter them out(based on dart: scheme) and add them to incremental component when reject request has to be processed.

[jensjoha]

Should have been fixed by 2087d6d.