When outputting the name of a type parameter, Kernel follows two
special conventions:
- It fully qualifies the name of the type parameter with respect to
the scope of its declaration; so for example a type parameter `T` of
a class `C` in a library `lib` might be annotated as `lib::C::T`.
- Within a factory constructor, type parameters of the class are
annotated as though they are type parameters of the factory
constructor (this is because factory constructors are represented in
kernel as static methods).
This CL adjusts the strong mode type inference tests to reflect this
behavior (and modifies analyzer's front_end_inference_test so that
follows the kernel conventions).
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2909503004 .
Factory constructors are represented as static methods with dynamic
return type; in order to type infer them properly we must use the type
of the enclosing class as the return type (with type parameters
substituted appropriately).
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2900553003 .
This CL makes the following fixes:
- Updates analyzer's front_end_inference_test to represent the bottom
type as "<BottomType>" (consistent with Kernel).
- Implements type inference of "throw" expressions.
- Does not coerce bottom to dynamic when inferring the return type of
a closure.
- Does not coerce Null to dynamic when inferring the return type of a
block closure.
- Ignores bare "return;" statements when inferring the return type of
a block closure.
- Infers Null when a block closure lacks "return <expression>;"
statements.
- Implements correct rules for LUB(Null, x), by treating Null as
bottom.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2886873005 .
- Add num::== and Iterable::where to analyzer mock SDK.
- Do not default parameter types to dynamic in BodyBuilder or
KernelFormalParameterBuilder. This is now handled by the
KernelVariableDeclaration constructor.
- Only infer function expression parameter types in strong mode.
- Record inferred function expression parameter types to
instrumentation.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2886443003 .
We need to compute the interface target in order to do the inference
anyway, so this is a reasonable time to store it.
Also annotate the inference tests with interface targets so that we
can verify that the interface targets computed by analyzer match those
computed by Fasta. Note that this causes a few strong mode tests to
fail that were previously passing, due to the fact that type inference
in Fasta is incomplete.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2874033003 .
This was broken for three reasons:
- We weren't recording the fact that the type parameters were
explicitly provided, so the inference code path to handle this case
wasn't being exercised.
- The inference code path to handle this case was accidentally
referring to the `inferredTypes` variable, which is `null` in this
case.
- We were not checking for the case where the user provided the wrong
number of type parameters.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2874053002 .
Previously, we only annotated "promotedType" for local variables; we
need to annotate it for function parameters as well.
Note that a few Fasta tests start failing as a result of this change,
due to the fact that the Fasta type promotion/inference logic is not
yet complete.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2868133002 .
Three problems are fixed:
- I forgot to pass the `downwards` flag when doing downwards inference.
- I forgot to initialize the `formalTypes` and `actualTypes` arrays.
- I wasn't tracking whether constructor type arguments were implicit
or explicit, so constructor type inference wasn't actually
happening.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2864853002 .
Front_end wants to annotate instance creations like this:
new /*@typeArgs=Foo*/ bar();
Whereas the existing tests use this style:
/*@typeArgs=Foo*/ new bar();
It's easier to modify the analyzer code to use the front_end style
than to update the front_end to use the analyzer style, and besides, I
think the front_end style makes more sense.
I've also added a boolean to front_end_inference_test.dart to allow
expectations to be updated more easily in the future.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2867113002 .
Paul Berry