Strong-mode should fill omitted type parameters with type bound instead of dynamic?

[ochafik]

Context: I found many usages of class Rectangle<T extends num> with the non-generic raw type Rectangle. Seems like it's treated by strong-mode as Rectangle<dynamic>, while it would seem it could / should be Rectangle<num>:

import 'dart:math';

foo(Rectangle r) => bar(r);
//                      ^
// [error] Unsound implicit cast from Rectangle<dynamic> to Rectangle<num>
bar(Rectangle<num> r) => null;

(tested with 1.16.0-dev.2.0)

[ochafik]

cc/ @leafpetersen

[leafpetersen]

This might be an instance of #26265 . Are you seeing this in the IDE or the command line? If in the IDE, can you wait until analysis stabilizes, edit the file in a way that causes re-analysis (say insert and remove a space from the middle of the word 'Rectangle'), and see if it fixes itself?

[jmesserly]

yeah and FYI, the original fix was in #25877

[ochafik]

I'm seeing this in command line (dartanalyzer --strong math.dart).

Note: also happens with 1.16.0-dev.5.4, but that fix (ce806bf) seems to have made it to all 1.16.0-dev.x versions anyway.

[ochafik]

If I define my own local Rectangle, it works: could it be that it treats type info from the sdk differently?

class Rectangle<T extends num> {}
// OK
foo(Rectangle r) => bar(r);
bar(Rectangle<num> r) => null;

For the record: it does know that the bound is num, as the following code fails:

import 'dart:math';
Rectangle<String> r;
//        ^
// [error] 'String' does not extend 'num'

[jmesserly]

FYI, I'm seeing "no issues found" on your original example. Using a bleeding_edge build (864b64f)

[leafpetersen]

@jmesserly can you double check? I see the issue with latest dev release, and with bleeding edge analyzer.

[jmesserly]

Oh sorry! I was hitting the bug where running from the wrong directory, --strong is ignored :(

[bwilkerson]

I can reproduce this using the command-line analyzer, but if I open the same file in my IDE (in a project that enables strong mode) I don't get an error. If I hover over either occurrence of r in the line

foo(Rectangle r) => bar(r);

it reports that r has the static type of Rectangle<num>. (Without strong mode enabled the static type is Rectangle<dynamic> as expected.)

To save time running this down, does anyone know where the substitution of the bounds for the missing type argument is happening?

[jmesserly]

To save time running this down, does anyone know where the substitution of the bounds for the missing type argument is happening?

TypeSystem.instantiateToBounds is where we handle the difference.

It needs to be called any time we want the "default instantiation behavior". For foo(Rectangle r), IIRC TypeResolverVisitor is the one that resolved parameter types?

[jmesserly]

IIRC, it should be happening on this line:

sdk/pkg/analyzer/lib/src/generated/resolver.dart

Line 9747 in fc55cb9

type = _typeSystem.instantiateToBounds(type);

[bwilkerson]

Thanks! That's exactly where it should happen. But for reasons I don't understand yet, the type parameter for Rectangle doesn't have a bound (which explains why it isn't being used).

[jmesserly]

Oh crazy! Shot in the dark: maybe it fails to deserialize it from the SDK summary or something like that?

[bwilkerson]

Thought about that. Konstantin says we're not using summaries anywhere yet. Also, I can see in the debugger where we're resolving and setting the bound (though I haven't been able to find where it's being cleared), which tells me we're not using summaries because we're following the old code path to resolve dart:math.

[bwilkerson]

I believe that this is caused by a bug in the task descriptions: we're not requiring that the bounds for classes in imported libraries be resolved before resolving types in the importing library. But as Konstantin pointed out in #26265, there are also ordering issues even when the types are all defined in the same compilation unit.

[leafpetersen]

Closing this as a duplicate of #26265 since I think that bug captures the issue here. If there's something additional about this bug that's not captured there, feel free to reopen.