This reinserts the native spec-string interpretation.
The CL https://codereview.chromium.org/2004833003/ changed the interpretation of `List` from `List<E>` to `List<dynamic>` causing these native classes to be added through subtyping:
NativeUint8List <: List
NativeUint8ClampedList <: List
NativeUint32List <: List
NativeUint16List <: List
NativeInt8List <: List
NativeInt32List <: List
NativeInt16List <: List
NativeFloat64List <: List
NativeFloat32List <: List
NativeTypedArrayOfInt <: List
NativeTypedArrayOfDouble <: List
R=sra@google.com
Review URL: https://codereview.chromium.org/2021723003 .
This CL adjusts the treatment of initializing formals, such that they
can be used in initializers and in constructor bodies. E.g., `x` can be
used as in `C(this.x) : y = x { var z = x + 2; }`.
It hides the new feature under the option '--initializing-formal-access'
which is used in the test 'initializing_formal_access_test.dart'.
It also adds an `example` test to `MessageKind.DUPLICATE_DEFINITION` to
verify that name clashes among initializing formals and other
parameters are detected (which was previously not the case).
Finally, it fixes a typo in a comment, `InitializingFormalParameter` ->
`InitializingFormalElement`.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/2025853002 .
This CL changes the response to `x is T`, `x is! T`, `x as T`, and `T`
used as a type expression (say, `foo(T)`) where `T` is a method type
variable: It will now emit a warning in these cases.
Test examples associated with `TYPE_VARIABLE_FROM_METHOD_NOT_REIFIED`
have been activated and corrected, such that this behavior is tested.
As a result 'language/generic_methods_type_expression_test.dart' will
now cause warnings when compiled with `dart2js`.
Note that this does not break any tests, because `dart2js` does not make
the compilation fail when there is a warning (also, the analyzer and the
vm are unaffected because this is about a change to `dart2js`, not a
change to the test file).
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/2001093006 .
This basically removes the dependency on source-mirrors from the try site and will let us delete source-mirrors from the compiler.
I was a torn for a bit about how to replace the logic here. I considered these 4
options:
(a) directly use the compiler internal APIs to crawl for reachable libraries.
(b) use `analyze-all`, then iterate over the resolved libraries.
(c) avoid parsing altogether, just enumerate recursively all files under
sdk/lib/ and create the json file that way.
(d) submit a fixed version of the sdk, since we unlikely need it up-to-date
for the site/try tests
I decided decided to go with (c) in this CL. It's simple and, given that the
only purpose is to preserve the site/try tests until we replace them, it seems
like the option that will slow us down the least (it makes the .json file
bigger, but that's OK now that this is not a service in use). It seemed
unnecessary to do full resolution, so I wasn't convinced of doing (b), but I did experiment with (a) now that we are
making the frontend libraries easier to use on their own. The result was OK (see
https://codereview.chromium.org/2003233002/), but probably not worth submitting
because we'd have to remember to update the code every time we modify the
internal dart2js APIs. I rather have the code in that CL be a test instead.
R=het@google.com
Review URL: https://codereview.chromium.org/2006993002 .
This CL has the same purpose as 1969753002, stated in the title line,
but it works for checked mode execution (where 1969753002 was broken),
and for usage of method type arguments in additional situations.
Approach: `DartType` and subtypes have been extended with new methods
to erase `MethodTypeVariableType` to `DynamicType`. This is done early
(after resolution, before SsaBuilder), such that only few parts of the
compiler need to deal with anything new. This approach handles method
type variables in checked mode, in `new` expressions, and in function
typed parameters. Finally, tests are added for the new cases, and
status files updated.
UPDATE: See message #10 and #12 for an updated description of the approach.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1976213002 .
This CL changes `Types.getClassContext` to return null for method type
arguments (indicating that the given `type` does not contain any type
variables, which fits the current "ignore them" approach to that kind
of type variable). It introduces a new class `MethodTypeVariableType`
which models a method type variables and ensures that it is treated
as `dynamic` (such that type annotations are permissive, and usages
as a type expression `T` in `.. is T` or `.. as T` are treated like
a malformed type). For RTI, method type variables are ignored (such
that no additional classes are claimed to be needed for RTI due to
method type variables, no matter how they are used). Finally,
`SsaBuilder.addTypeVariableReference` generates code yielding the
value `dynamic` for method type variables.
Adresses issue 26436.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1969753002 .
Johnni Winther