The argument type ‘x’ can’t be assigned to the parameter type ‘x’

I think we’ve seen this before on Windows and believed it to be imports mixing ‘package:’ and relative paths, however I’ve just hit this today on a framework type:

file: 'file:///m%%3A/Coding/Applications/flutter/packages/flutter_tools/lib/src/doctor.dart'
severity: 'Error'
message: 'The argument type 'Iterable<DoctorValidator> (M:\Apps\Dart\Dart-2.0.0-dev.20.0\lib\core\iterable.dart)' can't be assigned to the parameter type 'Iterable<DoctorValidator> (M:\Apps\Dart\Dart-2.0.0-dev.20.0\lib\core\iterable.dart)'.'
at: '47,28'
source: 'dart'
code: 'argument_type_not_assignable'

Note that the types are the same:

'Iterable<DoctorValidator> (M:\Apps\Dart\Dart-2.0.0-dev.20.0\lib\core\iterable.dart)'
'Iterable<DoctorValidator> (M:\Apps\Dart\Dart-2.0.0-dev.20.0\lib\core\iterable.dart)'

The source code is this revision:

DanTup/flutter@601655b

Originally the VsCodeValidator.installedValidators returned a List (not Iterable) but I got an equally confusing message (can’t assign the list to an argument of iterable) so I change it to iterable while debugging and then it still complained.

I can try this on my Mac later, but I wouldn’t be surprised if this was Windows-only given the previous similar error we had was.

Author: Fantashit

3 thoughts on “The argument type ‘x’ can’t be assigned to the parameter type ‘x’

  1. Actually, this is the same issue – I used the code-fix to add the import and it added it was a package: uri (I did look at this before I posted, but obviously not well enough!).

    Changing import 'package:flutter_tools/src/vscode_validator.dart'; to import 'vscode_validator.dart'; fixes it.

    I found the other issue – it’s #28895.

  2. Yep. In Dart, two libraries are the same if, and only if, they are imported using the same URI. If two different URIs are used, even if they resolve to the same file, they will be considered to be two different libraries and the types within the file will occur twice, leading to exactly this problem.

    As a result, the recommendation used to be that you always use a package: URI to import code from within the lib directory, even when the importing library is within the lib directory. Doing so will avoid this problem. Partially as a result of that recommendation, analyzer is written to assume that every library within the lib directory was originally referenced using a package: URI (for the purposes of computing identity). Similarly, we intentionally made the quick fix insert a package: URI in order to make user’s code consistent with this recommendation.

    That said, the opposite approach also works. If all URIs within a package are always relative (and two packages are not mutually recursive), then you still avoid this problem. (If you have mutually dependent packages, then using package: URIs everywhere is the only sure solution.)

    The key is to be consistent. Unfortunately, the tooling assumes the former scheme, and doesn’t maintain consistency for the latter scheme.

  3. I had this issue too, and it took me a while to figure out why.

    Turns out one file still had the import with the all-lowercase directory name “models”, and another used the capitalized “Models”.

    I find it strange that android-studio still accepted the import as valid, even though the directory name wasn’t all-lowercase anymore. Especially since whether it was capitalized or not, it still pointed to the same file if I ctrl+clicked on it.

Comments are closed.