This implements FutureOr<T> in strong mode, otherwise it's ignored (treated as `dynamic`.
Also fixes strong mode's inference subtype function incorrectly treating `void` as a malformed type. This had the consequence of allowing `void` to be inferred as a type argument.
R=leafp@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2647833002 .
This ensures the runtime type is of the tear-off expression's static
type, even when accessed through a superclass.
I also moved the two tests into a subdirectory so they are easier to
find. (It is inscrutable to me why we would have a single directory
with 1,868 test files in it.) That involved enabling recursive
directory listing in codegen_test, which exposed a couple of things.
Fix#27484.
R=leafp@google.com
Review-Url: https://codereview.chromium.org/2641543003 .
This CL creates top level accessor functions which may be used to map from AST data structures to their corresponding elements and types, and begins using those accessor functions throughout the SDK. It also adds empty interfaces ResolutionTarget and ResolutionType, which are implemented by Element and DartType respectively.
In a future CL, I will change the types stored in the AST to ResolutionTarget and ResolutionType, rather than specific element types; this will decouple the ASTs from the element model. The presence of the accessor functions will allow clients to continue accessing elements and types in a type-safe way.
R=asgerf@google.com, brianwilkerson@google.com, scheglov@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/2551023005 .
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 .
* 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 .
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 .
Janice Collins