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 analyzer keeps a separate AnalysisContext for the SDK, and the
options we set on our own context did not match those on the SDK,
mainly causing issues for strong mode.
Also, the BatchModeState is now used to share the Dart SDK, instead of
using a single instance held in a static variable.
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/504827013 .
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 .
Some backend targets require extra libraries that are not used
explicitly by a program (e.g., the Dart VM requires its bootstrap
libraries). Add a target-specific list of these libraries and ensure
that they are loaded when loading a program from Dart sources.
BUG=
R=asgerf@google.com
Review URL: https://chromereviews.googleplex.com/495497014 .
For example:
class A extends Foo<int> with Bar<String> {}
class B extends Foo<int> with Bar<double> {}
becomes:
class Foo&Bar<S,T> = Foo<S> with Bar<T>;
class A extends Foo&Bar<int, String> {}
class B extends Foo&Bar<int, double> {}
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/493197013 .
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 .
Make sure the 'index' field we generate corresponds to the Element
from the analyzer's model.
As it is now, this does not cause any reproducible errors since the
Element for the 'index' field is never referenced, but this will change
as we introduce interface targets in strong mode.
BUG=
R=kasperl@google.com
Review URL: https://chromereviews.googleplex.com/497607013 .
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 .
Asger Feldthaus