Previously this was working for a few use cases by dumb luck, but it
wasn't well tested and became broken by
b29c6bf330. This CL fixes it for real
and adds tests to verify the fix.
Note that there is a change to how we represent an unresolved
import/export: instead of storing a URI_EXISTS modifier in the element
model, we simply mark the imported library element as synthetic.
(This library element existed anyway; we just weren't marking it as
synthetic). This makes it easy to tie in with summaries, since it is
easy for the resynthesizer to detect that the library doesn't exist at
the time the library handle is resolved.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2235373003 .
Instead of a very slow .inDeclarationContext() method which determines
whether a given identifier is in a use position or not, we just create
a different subclass at parse time that encodes that fact directly.
Also, remove an unnecessary _validateElement() method.
On my Mac laptop, this takes benchmark/errors_in_all_libraries.dart
From: 0:00:05.673849
To: 0:00:05.193563 (91.53%)
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1833573006 .
Adds a `TimedAstVisitor` that wraps and times base visitors. The perf hit for collecting timing was neglible so I opted to NOT surface a way to not collect the data. We can add that if needed.
Once this is published in a new analyzer, I can bake client support into (for example) the linter.
More context and a client mock here: https://github.com/dart-lang/sdk/issues/24548
BUG=
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1807723002 .
This gets us roughly half+ way there. We should defintely consider automating this to speed up the rest. (Even with the quick-fix it's VERY tedious and slow going.)
Once we've done this in bulk, I'd like to add the `annotate_overrides` lint to analyzer and server `.analysis_options`.
BUG=
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1749143003 .
* Defines `isProtected` accessors.
* Adds a simple mechanism to our test `AnalysisContextFactory` allowing us to contribute package resolution to test cases.
* Adds `meta` awareness to `ResolverTest`.
NB: this *only* adds method invocation support. I'll generalize to all members in a follow-up. There's enough here though that I wanted to get some early feedback.
BUG=
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1723243002 .
* we now push the context return type down when inferring
* we also take this into account in our initial downards inference for arguments
* adds a common AST interface for FunctionExpressionInvocation and MethodInvocation, so we can handle these more uniformly
R=brianwilkerson@google.com, leafp@google.com
Review URL: https://codereview.chromium.org/1720433002 .
These data structures provide the same functionality as
VariableElement.isPotentiallyMutatedInClosure and
VariableElement.isPotentiallyMutatedInScope, but are only accessible
from a resolved AST. In a later CL,
VariableElement.isPotentiallyMutatedInClosure and
VariableElement.isPotentiallyMutatedInScope will be deprecated.
R=brianwilkerson@google.com, jmesserly@google.com
Review URL: https://codereview.chromium.org/1700263002 .
In the process, I fixed a bug where one version of this same lump of
code wasn't correct anymore now that you can have arbitrarily long
chains of type parameters.
DartType isn't maybe the ideal place for resolveToBound(). I wanted it
somewhere that:
1. Would be obvious enough that someone coming along later would
discover it instead of reinventing it again.
2. Had access to the various data it needs.
3. Wouldn't need a "is TypeParameterType" guard at every callsite
before it could be used.
I could put it on TypeProvider instead, since it needs access to Object,
but that felt arbitrary.
It could be a top level function, but then I don't think it would be
very discoverable.
R=brianwilkerson@google.com, jmesserly@google.com
Review URL: https://codereview.chromium.org/1686893002 .
Brian Wilkerson