Type resolution should use the downwards inference type

[leafpetersen]

This code results in a no such method error on the call to bar on getBar():

class Foo {
  void bar() { print("hello"); }
}

class Bar {
}

dynamic getBar() => new Bar();
dynamic getFoo() => new Foo();

main() {
  Foo foo;
  foo = getFoo()..bar();
  /// The following gets treated like:
  /// foo = (getBar()..bar()) as Foo;
  /// instead of the more useful
  /// foo = (getBar() as Foo)..bar();
  foo = getBar()..bar();  
}

We seem to be correctly using a downwards inference context to fill in types in cascades, but resolution doesn't mark getBar() as having type Foo, with the associated implicit cast placed around the getFoo() call directly. As a result, we provide poor completion results.

In general, this applies to all composite structures like list literals, conditional expressions, etc. We will give better completion results and better user error checking if we push the type inwards.

[leafpetersen]

cc @stereotype441 @jmesserly who have been discussing cast placement in kernel

[jmesserly]

yeah that seems like an oversight. Cascades should definitely be getting the context pushed down to the target. Especially since it's a common initialization pattern, which exactly when the context type is most useful .

[jmesserly]

FYI @leafpetersen -- I also noticed bool context was not pushed down consistently, so I went ahead and fixed that. It's tied up in my CL that attempts to introduce T JS<T>(...) -- it became apparent that many things did not have a bool context as expected.

[leafpetersen]

Yes, I never got a change to go through the language grammar and exhaustively make sure that we were using all of the contexts that were available, so I'm sure we're still missing a number of them. :(

[stereotype441]

I think front_end already handles cascades correctly, but I'll double check.

@jmesserly, regarding bool, can you point me to your CL so I can verify that front_end implements the necessary bool contexts correctly as well?

[jmesserly]

@stereotype441 -- yeah, I owe you that CL. It's caught up in one of my many outstanding DDC perf CL's, I'll try to disentangle that so I can send it out.

[jmesserly]

I think this is a duplicate of #31792

[jmesserly]

ah that one is for CFE; will reopen. I think you're looking at Analyzer though Leaf?

[srawlins]

No more errors on this code.