Make type rules more flow sensitive.

[stevemessick]

[ed note: The analyzer actually has enough information to remove this warning, as indicated by the syntax highlighting of "err.reasons" -- 'reasons' is known to be a member. However, the spec says the editor MUST display the warning, so it does.]

ldap: codefu

Still seeing random places where the editor can't tell the type. In the screen shot there's one path that checks if the error is not a CodeError and returns. Later err is still listed as "Object" and thus there's yellow squiglies.
////////////////////////////////////////////////////////////////////////////////////
Editor: 1.4.0.dev_06_04 (2014-05-12)
OS: Linux - amd64 (3.2.5-gg1336)
JVM: 1.7.0-google-v6

projects: 5

open dart files: 41

auto-run pub: true
localhost resolves to: 127.0.0.1
mem max/total/free: 1778 / 1039 / 770 MB
thread count: 51
index: 621951 relationships in 110530 keys in 758 sources

SDK installed: true
Dartium installed: true

---

Attachment:
screenshot.png (515.20 KB)

[stevemessick]

The code in question is roughly this.

m(Object err) {
  if (err is! SomeClass) {
    return;
  }
  err.field.doSomething();
}
class SomeClass {
  String field;
}

"field" is highlighted as a member.

[jtmcdole]

Personally, I could care less about the spec when it does annoying things like "throw a warning on perfectly good code".. making larger projects look like they are littered with warnings. Over-warning is bad because people start turning a blind eye.

[gbracha]

So what this is actually about is more flow sensitive type rules. We started along this path with type promotion, and one can imagine doing more. I'll change the summary so it actually conveys this.

---

Set owner to @gbracha.
Removed Type-Defect label.
Added Type-Enhancement, Accepted labels.
Changed the title to: "Make type rules more flow sensitive.".

[munificent]

We are working on a proposal now that addresses this: #29624

[lrhn]

Done! 😁