- Serialize nativeMethodBehavior, nativeFieldLoadBehavior and nativeFieldStoreBehavior.
- Add a test for the serialization/deserialization of native data for dart:html.
R=het@google.com
Review URL: https://codereview.chromium.org/2057993003 .
Cache the value of the properties `isFromEnvironmentConstructor`,
`isIntFromEnvironmentConstructor`, `isBoolFromEnvironmentConstructor`,
and `isStringFromEnvironmentConstructor` in ConstructorElementCommon.
R=het@google.com
Review URL: https://codereview.chromium.org/2060143002 .
NativeBehavior for method calls and field load/store are now computed
during resolution and apply as part of the world impact. This prepares
for (full) serialization/deserialization of native elements.
R=het@google.com
Review URL: https://codereview.chromium.org/2045223002 .
This CL should fix the problem that arose with commit
543a51ff3e. Here's the description from
that CL:
This CL adds tests for previously uncovered elements of the semantics
and includes fixes such that the desired behavior is obtained. In
particular, an `isInitializingFormal` element may now occur in contexts
where it wasn't expected until now, and changes were made to handle it.
It is also checked that a capture of an initializing formal (in a
function literal) captures the parameter, not the field.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/2042293002 .
This CL adds tests for previously uncovered elements of the semantics
and includes fixes such that the desired behavior is obtained. In
particular, an `isInitializingFormal` element may now occur in contexts
where it wasn't expected until now, and changes were made to handle it.
It is also checked that a capture of an initializing formal (in a
function literal) captures the parameter, not the field.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/2039833002 .
The modelx implementation of getDefaultConstructor() (surprisingly)
returned constructors with only optional arguments. This CL aligns the
modelz implementation with this, adding a TODO to figure out what the
best behavior is.
R=sigmund@google.com
Review URL: https://codereview.chromium.org/2033893004 .
This CL removes the [intEnvironment], [boolEnvironment] and [stringEnvironment]
from [Compiler] and instead determine .fromEnvironment directly from the
constructor element itself.
R=sigmund@google.com
Review URL: https://codereview.chromium.org/2033383002 .
This CL fixes crashes in deferred_load when using serialized dart:core:
- resolution impacts are cached in [Resolution] for both serialized and unserialized elements.
- type variable constants (for mirrors) are computed using [ConstantExpression]s.
- LibraryElementZ.getImportsFor returns the empty list; thus still not valid for deferred access in serialized code.
R=sigmund@google.com
Review URL: https://codereview.chromium.org/2034973003 .
Previously the non-final static fields were pulled from the constant compiler.
Now, since all fields have a valid [constant] field, these fields are now computed
directly from the set of all referenced static fields.
R=sigmund@google.com
Review URL: https://codereview.chromium.org/2024873002 .
This CL is an adjusted version of CL 2025853002, adding updates to
`InitializingFormalElementZ` to match the updates applied to
`InitializingFormalElementX`, and adding the new option to the
`MessageKind.DUPLICATE_DEFINITION` example.
Description from 2025853002:
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/2029003002 .
The equivalence of unnamed mixin applications cannot be tested directly since
they are not nominal entities. In the example below two classes by the synthetic
name `S+M` are introduces. This CL adds a reference to the introducing class so
that the unnamed mixin applications can be distinguished as `S+M from C1` and
`S+M from C2`.
class S {}
class M {}
class C1 extends S with M {}
class C2 extends S with M {}
R=sigmund@google.com
Review URL: https://codereview.chromium.org/2017903002 .
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 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 .
Johnni Winther