Skip to content

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

Closed
@mraleph

Description

@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?

Activity

zoechi

zoechi commented on Jan 20, 2019

@zoechi
Contributor

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

DanTup commented on Jan 20, 2019

@DanTup
Collaborator

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

lrhn commented on Jan 21, 2019

@lrhn
Member

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

peter-ahe-google commented on Jan 21, 2019

@peter-ahe-google
Contributor

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

peter-ahe-google

peter-ahe-google commented on Jan 21, 2019

@peter-ahe-google
Contributor

We have a reproduction. More details will follow.

jensjoha

jensjoha commented on Jan 28, 2019

@jensjoha
Contributor

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.

added
area-vmUse area-vm for VM related issues, including code coverage, and the AOT and JIT backends.
and removed on Jan 28, 2019
peter-ahe-google

peter-ahe-google commented on Jan 28, 2019

@peter-ahe-google
Contributor

@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

aam commented on Jan 28, 2019

@aam
Contributor

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

aam

aam commented on Feb 4, 2019

@aam
Contributor

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

a-siva commented on Feb 19, 2019

@a-siva
Contributor

is this issue resolved?

aam

aam commented on Feb 19, 2019

@aam
Contributor

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

jensjoha commented on Feb 25, 2019

@jensjoha
Contributor

Should have been fixed by 2087d6d.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area-vmUse area-vm for VM related issues, including code coverage, and the AOT and JIT backends.customer-flutter

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @mraleph@aam@zoechi@DanTup@lrhn

      Issue actions

        confusing error: The argument type 'dart.core::String' can't be assigned to the parameter type 'dart.core::String'. · Issue #35715 · dart-lang/sdk