* 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 .
Previously, we had a special class,
ConstantEvaluationTarget_Annotation, for this purpose. It held on to
a the AST node for the annotation. This was bad because it meant that
the presence of any ConstantEvaluationTarget_Annotation referring to a
given compilation unit would keep the entire compilation unit's AST in
memory.
Now we copy just the portions of the AST we need into
ElementAnnotation, just as we do for all other constant evaluation
targets. In addition to saving memory, this paves the way for
supporting annotations in summaries, by making it possible to compute
the constant value of an annotation without having to consult the full
AST.
Fixes#25285.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1665353002 .
Previously, we would precompute the value of ClassElement.isValidMixin
and store it in the Modifier.MIXIN. But this didn't really save any
time, because (a) isValidMixin isn't used inside analyzer, and (b) it
is easily derivable from other information already present in the
element model.
Also, we were computing it incorrectly when the `--supermixin` flag
was present.
This CL replaces the precomputation logic with a direct implementation
in ClassElement.isValidMixin which is correct regardless of the
presence of the `--supermixin` flag. The tests are beefed up so that
(a) they validate correct behavior for both states of the flag, (b)
they validate correct behavior in the presence of factory
constructors, and (c) they validate that the behavior of
`isValidMixin` is consistent with the error messages produced by the
analyzer.
In addition to fixing bugs, the removal of Modifier.MIXIN means we
have one less piece of information to store in summaries.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1635063003 .
Introduces MethodInvocation.staticInvokeType to track the type of this invocation. This provides a natural place to store the instantiated generic function type. We then use this type when we are computing corresponding parameters or return types. As a result we do not need FunctionMember, and some of the code around generics becomes simpler/more uniform.
This approach should be a straightforward way to add support for generics in FunctionExpressionInvocation, in a follow up (see issue #25175).
Also renames "boundTypeParameters" to "typeFormals". "formals" and "actuals" is a pretty common way to describe these, I'm not sure why I didn't think of that better name originally. :)
Also removes broken ParameterMember.== that I had added in a previous CL. And the broken FunctionTypeImpl.originalFunction/instantiatedTypeArguments getters.
Finally, this fixes#23252 in the process of adding this. The return type of a "call" method was not being statically analyzed if the target was a VariableElement.
R=brianwilkerson@google.com, leafp@google.com
Review URL: https://codereview.chromium.org/1568643002 .
This does away with the expensive call to `computeDocumentationComment` in favor of cached comments. Notably this makes adding doc content to code completion proposals performant (and so is done here). It should also make `dartdoc` *much* faster for doc generation since there are no more trips to disk to fetch comments for elements (still needed for source though).
For more on the desire for docs in completions see here: https://github.com/dart-lang/sdk/issues/23694R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1534043002 .
Brian Wilkerson