We now check that classes and type parameters are not redeclared.
The verify_test also verifies that its test harness has no errors,
as this would make all the other tests useless.
BUG=
R=kmillikin@google.com
Review URL: https://codereview.chromium.org/2539743002 .
This replaces the old --sanity-check flag from dartk. Some files have
been renamed to avoid the wording "sanity check".
Compared to --sanity-check, the following checks have been added:
- variables are not referenced out of scope
- variables are not redeclared
- class type parameters are not referenced from static context
A unit test has been added to check that the verifier rejects certain
invalid ASTs.
BUG=
R=kmillikin@google.com
Review URL: https://codereview.chromium.org/2531873002 .
Sanity checks now run in a single pass rather than two, and
instead of building a set consisting of all members, it uses
a bit from the transformer flags to remember which members are
not orphaned.
As an additional check, it now checks that members are not
declared more than once.
R=kmillikin@google.com
Review URL: https://codereview.chromium.org/2529973002 .
FunctionType now has a List<NamedType> which must be sorted by name.
Previously, named parameters were stored in a Map<String, DartType>.
FunctionNode still has a List<VariableDeclaration>, but this list must
now be sorted by name.
BUG=
R=ahe@google.com
Review URL: https://codereview.chromium.org/2502343002 .
This is a piece of the upcoming strong mode-based type propagation.
The new type propagator will build its inference graph based on the
subtyping constraints found during type checking.
This type checker is not intended to report type errors to end-users.
In its current form, it is quite redundant with the front end's type
checker, but this will not be the case once we augment kernel's type
system.
The internals of "dart:" libraries are not type checked -- they are
simply assumed to satisfy the type annotations on their interfaces.
BUG=
R=kmillikin@google.com
Review URL: https://codereview.chromium.org/2465893002 .
Type annotations in the supertype clauses of a class are now Supertypes
instead of InterfaceTypes. In the current version, the two classes
contain the same information, but they are about to diverge in the
following ways:
- An InterfaceType may be nullable, whereas a supertype cannot.
- An InterfaceType may represent the exact class, a subclass, or
a subtype of the given class.
- The type arguments to an interface type represent bounds, whereas
the arguments to a supertype are always exact.
We also introduce a class Substitution that represents an operator
that replaces type parameters with types, depending on the variance
of their use site.
A substitution can be applied to a DartType or a Supertype, and can
be generated independently of how it will be applied.
BUG=
R=kmillikin@google.com
Review URL: https://codereview.chromium.org/2439043002 .
When visiting a generic function type in contravariant context, the
current variance bit would not be propagated to the inner visitor.
For example,
(<F>(T,F) => F) => int [bottom <: T <: String]
would erroneously map to:
(<F>(bottom,F) => F) => int
instead of:
(<F>(String,F) => F) => int
Generic function types cannot occur in contravariant position
using current Dart syntax, but it could possibly occur as an
intermediate type.
BUG=
R=ahe@google.com
Review URL: https://chromereviews.googleplex.com/521207013 .
When a class inherits two abstract members with the same name from
different supertypes, both members are now present the list returned
by ClassHierarchy.getInterfaceMembers. Previously, only one of the
member would be present.
This ensures that all override pairs can be detected, which in turn
is necessary for inserting covariance checks in strong mode.
Another change in this CL is that interface members are built
eagerly instead of on-demand. This makes the ClassHierarchy more
reliable when used for transformation, and easier to benchmark.
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/520907013 .
dartk and other command-line tools no longer rely on analyzer classes
like AnalysisContext or DartSdk, and instead use only the interface
defined in loader.dart.
The class AnalyzerLoader has been renamed to DartLoader.
The sharing of state in batch mode is now owned by loader.dart, so
dartk.dart does not deal with DartSdk and package_config.
Repository no longer has a package or SDK path. These concepts are
now specific to the Dart frontend. Consequently, loading a binary
file no longer relies on URI resolution.
The Repository class is now more clearly focused on linking symbolic
names to their IR objects, which for the time being is only
URI-to-library bindings, but should be extended to support linking
class and member references across different files and different
loaders.
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/512907013 .
A single suite of test files is now shared among these configurations,
each with their own expected outputs:
- spec mode
- strong mode
- spec mode w/ type propagation
Although some tests are going to focus on a specific configuration,
for now it seems easier to maintain a single set of tests.
No additional tests have been added in this CL, but the intention
is to start adding more tests.
The baseline tests no longer contain any checked-in dill files.
To simplify dependencies, these tests do not rely on a patched SDK,
which means the async transformer cannot currently be tested with
this framework.
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/507347013 .
This lets us substitute different values for a type parameter depending
on the variance of its use site. For example:
(T) => T
can be substituted with [bottom <: T <: num] to get:
(bottom) => num
which is the best upper bound that doesn't use T.
This generalizes the existing substitution method, since it's
complicated enough that I don't want to maintain two versions of it.
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/501577015 .
Calls are now printed as follows:
Dynamic calls: receiver.name
Interface calls: receiver.{target}
Direct calls: receiver.{=target}
Dynamic super calls: super.name
Super interfaces calls: super.{target}
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/502957013 .
The interface target can now be stored on PropertyGet, PropertySet, and
MethodInvocation If set, we know the concrete target overrides or
implements that member.
All expressions have a method getStaticType for computing its type,
which relies on interface targets for the expressions that have one.
Expressions whose type is a least upper bound have the type stored
explicitly, so the definition of least upper bounds is contained only
in the frontend.
This is a work in progress towards strong mode support, it is still
not complete.
Still missing in the frontend:
- checks from implicit downcasts
- parameter checks from covariant override or covariant generics
Implemented but not part of this CL:
- subtype tests
- IR type checker (for debugging)
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/496717014 .
This makes super calls name-based (no target) and add direct calls with
both receiver and explicit target.
Super call resolution translates the name-based super calls into direct
calls after they have been cloned into the mixin application.
For JS backends, it should suffice to clone mixed-in methods that
contain super calls, but that transformation is not part of this CL.
This also adds a --target option to dartk designating the target to
which the kernel IR should be specialized. The new transformation
is run when --target=vm.
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/486537013 .
We need the ability to efficiently transform a mixin application class
into a regular class, and the separation was obstructing it. It also
simplifies the IR a bit, although it no longer enforces the invariant
that mixin applications cannot contain fields and procedures.
The binary format is unchanged, so the separation still shows up in
there. This ensures the CL can land without any changes to the SDK.
BUG=
R=vegorov@google.com
Review URL: https://chromereviews.googleplex.com/488407013 .
There is a new lattice point for each class, representing the values
that are subclasses of it.
To ensure that subclassing information is valued higher than subtype
information, we exploit that the ordering of lattice points determines
how the join operation chooses between ambiguous upper bounds.
BUG=
R=kustermann@google.com
Review URL: https://chromereviews.googleplex.com/488627013 .
There is a new 'call handler' meta field in the constraint system,
unfolding any number of 'call' properties on the callee until a
function value is found.
Every method invocation must now load this field to ensure the actual
function is invoked. This adds quite a bit of overhead, but in strong
mode we should be able to avoid the extra load in practice.
BUG=
R=vegorov@google.com
Review URL: https://chromereviews.googleplex.com/485117015 .
Allocation of a value and bitmask input are two different constraints
in the constraint system. However, for all values other than 'null',
there should be exactly one bitmask input and one allocation constraint.
The bitmask input was omitted in some cases in the handling of
externals, which is fixed in this CL.
BUG=
R=kustermann@google.com
Review URL: https://chromereviews.googleplex.com/481187013 .
This adds a notion of bitmasks to the constraint system,
which will be propagated by the solver, and joined using
bitwise OR. The solver does not care what the bits mean.
These bits propagate nullability and other values that we
care to preserve when a good base class could not be found.
This also adds an interface in front of type propagation
that exposes the inferred types in an accessible manner.
BUG=
R=kustermann@google.com
Review URL: https://chromereviews.googleplex.com/483887013 .
Instance members are now cloned for every class that inherits it.
The constraint system now explicitly requires all values to be
created using `newValue()`.
There is now a notion of "unions" for representing sets of values.
For class values, unions correspond to types. For function values,
unions are based on overriding and method names.
The solver's internal map of type (Value,Field) -> Value denoting
the value of a given field has been removed.
The builder must instead register store and load locations for
every valid (Value,Field) pair. Dynamic stores assign into the
store location, and dynamic loads take the value from the load
location.
Final fields have no store location, so they cannot be polluted
by dynamic stores.
R=vegorov@google.com
Review URL: https://chromereviews.googleplex.com/455987013 .
Asger Feldthaus