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 .
We weren't always setting FunctionTypeImpl._isInstantiated correctly,
resulting in incorrect types in some rare corner cases. I've added a
public `isInstantiated` getter so that we can check this more
thoroughly in unit tests.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1569923002 .
These can be easily inferred at the time the summary is resynthesized
into an element model. This should make the summary size marginally
smaller, and make it easier to create summaries straight from the AST.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1565643002 .
If a marker is null, it won't be written. For all other strings,
they'll be written as they are, including the empty string.
This enables nicer output for languages that don't have begin/end
markers for doc comments, such as Python.
Previously, we had to jump through hoops to properly resynthesize
InterfaceTypeImpl.typeArguments and FunctionTypeImpl.typeArguments,
because the correct set of type arguments depends on the number of
type parameters, and that information wasn't available in the
prelinked summary. Now it is.
Note that typeParameters and boundTypeParameters still aren't
resynthesized properly (and are untested). These will be addressed in
a future CL.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1559123002 .
In a future CL, this should allow the element model to be
resynthesized from a summary more efficiently, since it won't be
necessary to consult the referenced elements when resynthesizing a
FunctionTypeImpl.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1555233002 .
This way we would be able to redirect to the SDK context, or get some
results from packages. Setting ResultProvider into AnalysisDriver does
not allow us to do this.
My quick and dirty experiment with using SDK summaries is broken now,
but I'm going to start updating actual SdkAnalysisContext using
summaries, if the bundle exists in the SDK.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1555073003 .
Downwards inference pushes the declared return type of a function down into the body in order to infer types for the returned or yielded values. The asynchronous and generator cases were not being fully handled correctly.
This CL changes the return context stack kept by the inference context to contain the type expected to be returned or yielded (rather than the declared return type). At each return/yield statement, this return/yield type is used to infer types for the returned/yielded expression. At each yield* statement, the return/yield type is wrapped into the appropriate stream/iterable type.
This CL also adds future flattening when doing downwards inference on awaited expressions to avoid inferring nested future types.
BUG=
R=rnystrom@google.com
Review URL: https://codereview.chromium.org/1555603002 .
This will make it easier to re-link summaries when a file changes,
since all the information that is needed from imported libraries will
be in the "public namespace" section of the summary.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1543403002 .
This way we solve a chicken-and-egg problem with TypeProvider.
Fix for referencing elements from non-first part.
Fix for TODO to update implicit fields for a getter/setter pair.
The type List has it, so I have to fix it to use for SDK summaries.
Add SummaryTypeProvider to use with SDK summaries.
It is initialized in two steps: first dart:core, then dart:async libraries.
resynthesizer = new SummaryResynthesizer(context, typeProvider,
_getPrelinkedSummary, _getUnlinkedSummary, context.sourceFactory);
_buildCoreLibrary();
_buildAsyncLibrary();
void _buildCoreLibrary() {
LibraryElement library = resynthesizer.getLibraryElement('dart:core');
typeProvider.initializeCore(library);
}
void _buildAsyncLibrary() {
LibraryElement library = resynthesizer.getLibraryElement('dart:async');
typeProvider.initializeAsync(library);
}
R=paulberry@google.com, brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1543313002 .
Previously, we were generating code like:
if (_value != null || _value == <default>) {
<store _value in the summary>
}
which meant that (a) default values were being unnecessarily stored in
the summaries, and (b) passing null to a summary Builder setter would
have caused a crash.
This CL modifies the code generator to output code like this:
if (!(_value == null || _value == <default>)) {
<store _value in the summary>
}
which has the intended behavior of treating `null` like the default
value, and suppressing the default value from appearing in the summary.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/1539953002 .
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 .
Paul Berry