Silent inconsistency in top level inference

[leafpetersen]

The code below should issue an error on the assignment to p, or should issue a warning that top level inference can not be performed. Currently it seems to work correctly on task model and CFE but not driver.

Passing on:

• dartanalyzer --strong
• Intellij (strong)
• ddc
• ddc -k

var x = y.map((a) => a.toString());
var y = [3];
var z = x.toList();

void main() {
  String p = z;
}

[leafpetersen]

cc @stereotype441 @scheglov @devoncarew @bwilkerson

[scheglov]

We disabled these errors in https://codereview.chromium.org/2983293002
Should we restore them?

[leafpetersen]

I don't think so, but I don't really know that the plan here is. What I understood from talking to @devoncarew is that the interim plan was that:

• Kernel supports top level inference
• Driver implements a subset of top level inference and warns about missing top level inference
• Task model goes away

I suspect that restoring those warnings is non-starter, at least as more than hints, since the migration would be prohibitive.

[scheglov]

Well, this is place where linker does not perform inference.
We probably can add inference for cases when arguments are not closures.

But it is explicitly disabled for function types.

sdk/pkg/analyzer/lib/src/summary/link.dart

Lines 2015 to 2021 in 977f4c7

	if (Linker._initializerTypeInferenceCycle != null &&
	Linker._initializerTypeInferenceCycle ==
	compilationUnit.library.libraryCycleForLink) {
	// We are currently computing the type of an initializer expression in the
	// current library cycle, so type inference results should be ignored.
	return _computeDefaultReturnType();
	}

[devoncarew]

I would change 'Task model goes away' to 'Task model doesn't guarantee correctness'.

@leafpetersen, should this be tracked in #32395?

[leafpetersen]

@leafpetersen, should this be tracked in #32395?

It's already there.

[stereotype441]

There are at least two root causes of this issue:

1. When summarizing a method invocation, we aren't storing information about the arguments. I have a CL out to fix this: https://dart-review.googlesource.com/c/sdk/+/46301
2. When doing type inference of a closure appearing inside an initializer expression, we don't appear to be passing the correct context information into the closure.

Once https://dart-review.googlesource.com/c/sdk/+/46301 lands, Leaf's example will give an error message, but it won't be entirely correct--it will say "A value of type 'List' can't be assigned to a variable of type 'String'", whereas the correct message is "A value of type 'List<String>' can't be assigned to a variable of type 'String'". The reason for the incorrect error message is root cause 2, which causes it to infer a type of Iterable for x, instead of the correct type, which is Iterable.

I will start working on the second root cause now.

[stereotype441]

I'm going to delay further work on this until #32525 is fixed, since fixing #32525 is likely to change the internal representation of expressions used during inference. If we're lucky, the fix for #32525 will be to share enough code with the AST-based type inference mechanism that this bug gets fixed in the process. If we aren't, I'll come back and look at this bug after #32525 is finished.

[devoncarew]

currently blocked on #32525

[devoncarew]

And, possibly the fix for #32525 will help here as well.

[stereotype441]

Fix out for review: https://dart-review.googlesource.com/c/sdk/+/48741/1..2