This information will be necessary when a change to a file forces
summaries to be relinked.
Note that the way we determine the prefix is a bit kludgy: we look at
the export namespaces of the imported libraries and arbitrarily choose
a prefix that points to the given element. This will give subtly
incorrect results if a name is reachable via multiple prefixes,
however this is unlikely to pose a problem in non-contrived use cases.
See the test
`fail_type_reference_to_type_visible_via_multiple_import_prefixes` for
a more detailed explanation of what might go wrong.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1574763002 .
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 adds tests for some cases where explicit or inferred invocation
of generic methods is not working yet, and also for an issue around
function typed parameters. The tests currently fail.
It also adds some missing calls to super.setUp that were preventing
solo_test from working correctly.
BUG=
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1568653002 .
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 .
Look at the following code.
main([p = double.INFINITY]) {}
In ConstantVerifier we validate the value of "p" and while doing this validate
the value of the ConstFieldElementImpl that corresponds to "double.INFINITY".
The problem is that we compute "double.INFINITY" in the task that requires
RESOLVED_UNIT_n, where "n" is too high. What we really need is just one value,
not all values, and of course not the resolved unit. And when we will use
summaries, we will be able to provide these values without using AST at all.
So, we need to explicitly require computation of the default value of "p",
an explicit dependency on "double.INFINITY" and its explicit computation.
Currently it still causes using ASTs, but we will change this soon.
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/1531233002 .
This CL makes the following changes to the mock SDK used by
AnalysisContextFactory.initContextWithCore:
- Getters created by the ElementFactory have their `synthetic`
property set correctly, and their corresponding synthetic fields
have their `final` property set correctly.
- The following class elements all have at least one constructor:
Function, Iterable, Iterator, Map, Null, StackTrace, Type, num,
double, _Proxy.
This allows resynthesize_test.dart's `test_core` to pass.
Also, some minor improvements are made to resynthesize_test.dart to
allow failures to be diagnosed more easily.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1532763002 .
I notied during reading idl.dart that I'd like to see highlighting and
search for type names in comment references like [PrelinkedLibrary.dependencies].
With this change we get highlighting, search and refactoring for both.
Navigation also works (*).
(*) does not work in IntelliJ - it does not parse Dart comments for reference expressions.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/1531613002 .
This improves how generic function types are modeled. In particular, we can now handle types like <T>T -> T, in printing, equality, and the type parameter is correctly removed when it is instantiated.
This preserves the existing lazy "substitute" operation, and makes the "instantiate" operation interact with it correctly. Given a type like:
{T/T}<S>T -> S
we can substitute S/T to get:
{S/T}<S>T -> S
then if we instantiate as <int> we'll get the correct:
{S/T, int/S}T -> S, which == S -> int
This also converts typedefs over to the new system, as this seemed like the most natural thing. (However this does *not* change how the type name is evaluated, in particular given the type name "F", where "F" is a typedef `<T>T -> T`, will result in the function type `{dynamic/T}T->T` exactly as it did before. If we want to write the type `<T>T->T` we will need a different mechanism.)
R=brianwilkerson@google.com, leafp@google.com
Review URL: https://codereview.chromium.org/1488383004 .
The test suite PoorMansIncrementalResolutionTest was turning on the
new task model during setup and turning it off during teardown; as a
result, any tests run after it were using the old task model.
The easy fix is to just stop trying to adjust the task model state in
this test suite, since the new task model is on by default now.
This should fix test breakages when run via pkg/analyzer/test_all.dart.
TBR=scheglov@google.com
Review URL: https://codereview.chromium.org/1497573002 .
Paul Berry