Incremental resolution inconsistency handles propagated type of final fields

[stereotype441]

With the new task model disabled, paste the following code into an empty file:

class Y {
  final x='hi';
  mth() {
    x.
  }
}

Then place the cursor after x. and request completions. Completions such as length and substring (which come from the String class) are shown.

Now delete the ., retype it, and request completions again if necessary (note that most editors automatically request completions when . is typed). Now the only completions shown are those defined on Object, such as hashCode and runtimeType.

It appears that incremental resolution is not reproducing the propagated type of x.

[scheglov]

Paul, what do you consider a bug - the fact that we get propagated type initially, or the fact that we lose it after incremental resolution? It seems that the last one. But AFAIK we decided that we don't propagate types for fields in the old task model. So, it should not have been set at all.

[scheglov]

Disabling propagated types for properties.
https://codereview.chromium.org/1386033003

[stereotype441]

Getting inconsistent results from incremental vs. non-incremental resolution concerns me most, and it looks like your CL fixes that. I suspect that not too long from now we're going to need to start doing type propagation on final instance fields (judging by the high priority assigned to issue #23001, which is the parallel issue for top level final variables). But we can address that in a separate effort.

[bwilkerson]

Note that with the support for strong mode we have all the plumbing in place. It should be fairly easy to implement this after we've moved to the new task model. (On the other hand, it becomes completely moot for folks using strong mode.)

[scheglov]

Done.
ef434d6