- Adds support for serialization/deserialization of ErroneousElement.
- Imports dart:core for serialized libraries.
- Fixes and tests reserialization for ResolvedAst.sourceUri
R=het@google.com
Review URL: https://codereview.chromium.org/2088233003 .
- 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 .
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 .
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 .
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
Committed: 565b30123c
Reverted: fa5b98126c
Review URL: https://codereview.chromium.org/2021723003 .
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 .
The new test is specifically for `dart2js --generic-method-syntax ..`,
executed programmatically using 'memory_compiler.dart'.
It verifies that each method type variable is treated as if it had
been an alias for `dynamic` (so the static analysis allows almost
all usages of these type variables, silently). Note that this behavior
is unlikely to be available with any other tools, and even `dart2js`
will behave differently when generic methods are implemented fully.
Hence, the new test will only be useful as-is during a transitional
period.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1939053002 .
Move serialization tests into subfolder
Move data files into data subfolders
Move tests with errors/warnings into quarantined subfolder
Skip packages/ folder in test
The latter three improves workflow in IntelliJ; providing error/warning free analysis of unittests (by exclusion of folders).
R=sigmund@google.com
Review URL: https://codereview.chromium.org/1934883002 .
This CL is a rebased and retested version of CL 1915123008,
'Implements support for ignoring method type arguments in
resolution'. That CL caused failures on dart2js-jsshell but it is
now confirmed that the failures were caused by another CL.
Review URL: https://codereview.chromium.org/1942763002 .
Extends `FunctionExpression` to hold the formal type variable
declaration syntax. Introduces `GenericElement` as a new superclass of
`TypeDeclarationElement`, allowing `FunctionElement` to have a getter
`typeVariables`. Changes `SignatureResolver.analyze` in several ways
to create and handle the new type variables. In order to avoid circular
ordering dependencies, introduced new scope classes such that the
function signatures can be computed without relying on themselves to
look up type variables (e.g., `FunctionSignatureBuildingScope`).
Finally, the mock_compiler and resolver_test.dart were adjusted to give
a `scope` argument to `new ResolverVisitor(..)` in order to get the
correct scopes in the new setup.
A few words about the approach:
The type of every method type parameter behaves as `dynamic`, because
its bound is (unconditionally, ignoring any bound syntax that might be
present) set to `const DynamicType()`. This preserves the property
that diagnostic messages about the type variables will refer to the
correct location in the source code.
Type arguments passed in send expressions are parsed but not added to
the abstract syntax and therefore not passed on to the resolution
phase; this means that all sends are treated as if they had no actual
type arguments, even when they do have them. Hence, actual method type
arguments are completely ignored.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1915123008 .
This CL adds support for parsing and ignoring declarations of type
parameters on methods and functions, and passing type arguments to
method and function invocations. The type parameters thus declared do
not get a representation during static analysis, so any usage will
cause warnings about undefined types; hence, this CL transforms usage
of generic methods from syntax errors to static warnings. A followup
CL will eliminate the static warnings.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1863053003 .
When landed, CL 1789553003 turned out to cause bot failures because
some libraries outside the compiler are importing compiler libraries
which have been updated. For instance, the tests in 'compiler/dart2js'
depend on several internal elements of the 'dart2js' compiler.
This CL updates these external dependents to work with the modified
library structure and class APIs of the compiler. A small adjustment
was applied to 'dart2js_incremental' as well.
No further dependents are believed to exist: Grepping in sdk for
relevant imports does not reveal any further imports of any of the
libraries in the compiler where the "interface" has changed, and
external clients are not supported (that is, imports in arbitrary
github repositories may or may not break if they use the compiler
internals, but we do not support this type of dependency so we won't
do anything to protect them against that type of breakage).
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1864433004 .
