According to the language spec (which we are trying to follow as closely
as possible in the implementation of summaries), a setter for `x` has a
name `x=`, hence a combinator like `show x` should show both the name
`x` and `x=`.
This has no immediate effect beyond the unit test for NameFilter (since
at the moment the only names which are affected by the behavior of
NameFilter are the names of classes, and they never end in `=`). But in
a future CL I plan to use NameFilter to help build public and export
namespaces, and once that lands I will need NameFilter to handle setters
properly.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1576173002 .
The prelinker is capable of rebuilding the "Prelinked" summary
information based on the "Unlinked" information. We will need to do
this in order to make efficient use of summaries when some files are
changed but not others, or when a pub package is upgraded but another
package that depends on it is left alone.
R=brianwilkerson@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1576743002 .
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 .
We have one List<int> in the summaries model, so we need to be able
to write these lists in FlatBuffers.
We could probably make it more general by adding the Writer interface
and use it for writing any lists, as well as replace specialized
methods like addInt32() or addInt8() with a general addScalarField().
But this will make clients code a little bigger. Thoughts?
R=paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/1568343002 .
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 .
Field formal parameters have some strange behaviors because they are
the only thing in the language where the implicit type (if not
specified) is not necessarily `dynamic`. So we should be careful to
test that we resynthesize them properly.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/1569893002 .
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 .
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 .
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 .
Brian Slesinsky