Lint that flags usages of implicitly-dynamic values #262
Conversation
ochafik
force-pushed
the
no_implicit_dynamic
branch
from
70b5525 to
8ba05cc
Compare
ochafik
force-pushed
the
no_implicit_dynamic
branch
from
8ba05cc to
286ac47
Compare
|
I pulled this branch and the intellij dart plugin reports the same warnings than travis. Also I don't know for sure what the policy is, but I think it would be a good idea to follow more closely https://www.dartlang.org/effective-dart/style/ I know there is a preference to sort methods alphabetically, though some of the code I have contributed does not follow that pattern, but IMO readability would improve if you place the public/inherited api methods before the private ones. I tend to use the java convention where the private methods are placed immediately after they are first used. |
|
I just realized that I might not be following the style guide, so that part might not apply. |
|
For strong mode, we are planning to add a |
|
dart-lang/sdk#25573 -- the Analyzer bug that I am looking at |
Used dart-lang/linter#262 to spot these
|
@ochafik : what's the status of this one? Needless to say, the world has changed a lot since you put this together... 😉 Is there anything worth pursuing? |
| final LintRule rule; | ||
| Visitor(this.rule); | ||
|
|
||
| Element _getBestElement(Expression node) { |
There was a problem hiding this comment.
Consider to use getCanonicalElementFromIdentifier method from DartTypeUtilities (if applies)
| bool _isImplicitDynamic(Expression node) { | ||
| if (node == null) return false; | ||
| while (node is ParenthesizedExpression) { | ||
| node = node.expression; |
There was a problem hiding this comment.
Consider call _isImplicitDynamic(node.expression)
| if (_isImplicitDynamic(target)) { | ||
| // Avoid double taxation (if `x` is dynamic, only lint `x.y.z` once). | ||
| Expression subTarget; | ||
| if (target is PropertyAccess) subTarget = target.realTarget; |
There was a problem hiding this comment.
Perhaps it would be good idea to create a method that return an iterable with all targets, for example when you have something like:
a.b.foo().c.d.bar()[3].baz();So if you can create a method, it could be also use in unnecessary_lambdas, where I had to do a similar check
|
@ochafik Have we abandoned this PR? |
|
@ochafik: this is looking a bit stale (and would need rebasing regardless). Closing for now; feel to re-open if you want to take another pass. Thanks! |
Designed as a strong-mode-friendly replacement for
always_specify_typesandalways_declare_return_typeslints (complains about implicit dynamics at call sites instead of on declarations).Accepts explicitly
dynamicvalues, and lints against implicit ones used as invocation targets or downcast in argument / assignment positions.cc/ @leafpetersen I believe you mentioned this kind of checks was on your radar for strong-mode, WDYT?