need type promotion

[jmesserly]

this is a very handy feature in Dart:

if (x is Foo) {
  // ... assume x is a Foo
}

[jmesserly]

fyi, noticed this is leading to some pretty bad SDK codegen ... lots of dynamic invokes that aren't needed

[vsmenon]

Yeah, I think this is because we're getting the type off of the Element instead of the AstNode in the checker. We should have the promoted type on the latter as we're using the analyzer's propagation rules.

[jmesserly]

aha, yeah, that's a good guess! I was wondering why this one didn't "just work" from their static type rules

[jmesserly]

also related: #239

[jmesserly]

hmmm, I haven't been able to reproduce this yet. But I recall seeing busted generated code with too many dinvokes. Going to keep looking.

[jmesserly]

ah, found some example brokenness:
lib/runtime/dart/async.js#L47-49

    static _getBestStackTrace(error, stackTrace) {
      if (stackTrace != null)
        return stackTrace;
      if (dart.is(error, core.Error)) {
        return dart.as(dart.dload(error, 'stackTrace'), core.StackTrace);
      }
      return null;
    }

however, I think it might be by design :\ ... from the Dart spec, 16.34 Type Test:

Let v be a local variable or a formal parameter. An is-expression of the
form v is T shows that v has type T iff T is more specific than the type S of
the expression v and both T != dynamic and S != dynamic.

and (slightly edited by me, for formatting):

We do not want to refine the type of a variable of type dynamic, as this
could lead to more warnings rather than less. The opposite requirement, that
T != dynamic is a safeguard lest S ever be the bottom type.

[jmesserly]

@vsmenon @leafpetersen and I looked at these. We believe the original bug was fixed (early on, DDC completely disabled type promotion in analyzer), however, there is clearly room for improvement. Tracking that in #274