[go: nahoru, domu]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make type rules more flow sensitive. #18921

Closed
stevemessick opened this issue May 20, 2014 · 5 comments
Closed

Make type rules more flow sensitive. #18921

stevemessick opened this issue May 20, 2014 · 5 comments
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). language-discussion type-enhancement A request for a change that isn't a bug

Comments

@stevemessick
Copy link
Contributor

[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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor
gbracha commented Aug 26, 2014

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.".

@stevemessick stevemessick added Type-Enhancement area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). labels Aug 26, 2014
@kevmoo kevmoo added type-enhancement A request for a change that isn't a bug and removed accepted labels Feb 29, 2016
@munificent
Copy link
Member

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

@lrhn
Copy link
Member
lrhn commented Jan 12, 2024

Done! 😁

@lrhn lrhn closed this as completed Jan 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). language-discussion type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

7 participants