The concept of a binary library file no longer exists.
A kernel file can contain any number of libraries, and some of these
libraries can be "external". To reference a class or member from
another build, the class or member must be declared in an external
library.
Members in an external library contain all their type information,
but have no body.
Classes in an external library have their hierarchy information
present, but are not guaranteed to contain all their actual members.
The idea is that references themselves don't really cross module
boundaries, but rather refer to a local definition whose body is
contributed from elsewhere, much like 'external' members in Dart.
A modular backend such as DDC should be able to compile from one of
these kernel files without needing to load auxiliary information from
summaries or other kernel files.
For whole program transformations or backends, a linking step, which
is not yet implemented, must merge classes and members in external
libraries based on their name.
External libraries share the same IR and binary format as ordinary
libraries. Transformations that affect the interface for a member
or class should transform the external libraries alongside with the
internal ones, ideally without needing to treat them any different.
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/516847013 .
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 .
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 .
Asger Feldthaus