improve type promotion in strong mode

[jmesserly]

[Edit Sep 17 2018, eernstg: This seems to be the most generic issue on the topic of improving promotion, so I'd like to position it explicitly as "the place to go" for this discussion; I've added a comment listing other issues related to this topic here. I'll adjust the labels accordingly.]

---

There are some cases where type promotion won't work. Found while investigating the state of dart-archive/dev_compiler#31.

It roughly falls into a few buckets:

• if the original type of T of v was dynamic, the test v is SomeType won't promote. This leads to some suboptimal codegen in SDK (see strong mode should allow type promotion from dynamic #25486)
• if the tested type S is not a subtype of T, the test won't promote. You'd have to track a union type.
• the type promotion is only valid in the body/else clause of that if statement. There's no analysis of the rest of the method, meaning patterns like if (v is! S) return; don't affect the type of v in the rest of the method body.
• from Sky, we've heard they would like to do assert(v is S); and have v be treated as S for the rest of the method. Sort of like an unchecked (in production mode) cast, similar to S v2 = v but not requiring a second variable name to be introduced.
• from package:yaml, assignment to the variable in a closure will disable all promotion, this is true even if that closure hasn't been defined yet (and therefore, cannot possibly mutate the variable).
• Constrained generic parameter like T extends Event, not promoting to a subtype of Event like InputEvent, see Stack trace from editor evaluating code in CompileTimeConst visitor #327
• If the variable is mutated, it won't promote. This is the case even if the mutation doesn't affect the type.
• If the type test wants to allow null, like if (v == null || v is T), it should promote to nullable-T

[jmesserly]

Moved from dart-archive/dev_compiler#274.

[nex3]

I'd like to propose that v == null promote V. I don't know the type theory well enough to say what— maybe dynamic?—but this would support the following pattern:

void fn(T v) {
  // ...
}

void fnTakesObject(Object v) {
  if (v != null && v is! T) return;
  fn(v);
}

This comes up when implementing collections, since they have a number of methods that take Objects but need more specialized behavior for values of the collection's type.

[jmesserly]

ah, good example. So right now that won't promote because of flow analysis (issue 3 above) but it'd be equivalent to this:

void fnTakesObject(Object v) {
  if (v == null || v is T) {
    fn(v);
  }
}

Doing || generally would take union types, but we could definitely special case null, since that works for any T.