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 .
Fields getters and setters should be implicit whenever possible
to ensure JS compilers can easily control how they are generated.
However, it is still useful to be able to take control of the getter
or setter in the IR. We should just refrain from doing so for common
cases, where it can have significant code size impact in JS.
We can use this to insert checked setters for fields that override
a setter with an incompatible type, or whose type references a type
variable.
There are two changes to facilitate this:
- Fields have two flags indicating if the implicit getter and/or
setter should be generated. If not set, there can be an explicit
getter/setter for it in the same class.
- Interface targets that reference a field now go through one
level of indirection. This lets us update interface targets in
the IR, which is necessary for redirecting calls to an explicit
getter or setter.
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/504357013 .
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 .
Allocate contexts to hold captured variables. Rewrite captured variable
access to context access. Outside of a local function, this is a single
indirection through a named context. Inside a local function it requires
traversing (a statically known number of) parent links.
R=ahe@google.com
Review URL: https://chromereviews.googleplex.com/507717013 .
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 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 .
Asger Feldthaus