Jens Johansen
17503caa05
Before this CL: If a library (say lib.dart) imports a file (say part.dart) that's actually a part (of some other library (say main.dart)) an error is given, but the "fake library" shortly representing the part is still "linked" into the libraries dependency list. This means that the component returned from a compilation is different from the combination of libraries one can get to if walking all LibraryDependency's. This also means that if we serialize the component we can't load it back in (https://github.com/dart-lang/sdk/issues/46706). It furthermore means that we have two different entities with the same fileUri and importUri. This CL rewrites a such import of a part to instead be an import of the "parent", i.e. if a library lib.dart imports part.dart that's a part of main.dart an error is issued, and the import is rewritten to be an import of main.dart instead. The same thing happens to exports. This alleviates the problems (i.e. no crashing if trying to load the dill, no referenec to a otherwise non-existing library etc), and has the added benefit of probably being what the user wants: Anything defined in part.dart (that isn't private) is still in scope from lib.dart. Change-Id: I17aca9db4edbf25b23d3ef301cf65589eeeb1635 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213344 Reviewed-by: Johnni Winther <johnniwinther@google.com> Commit-Queue: Jens Johansen <jensj@google.com>
Dart Kernel
Dart Kernel is a small high-level language derived from Dart. It is designed for use as an intermediate format for whole-program analysis and transformations, and to be consumed by codegen and execution backends.
The kernel language has an in-memory representation in Dart and can be serialized as binary or text.
Both the kernel language and its implementations are unstable and are under development.
This package contains the Dart part of the implementation and contains:
- A transformable IR for the kernel language
- Serialization of kernel code
Note: The APIs in this package are in an early state; developers should be careful about depending on this package. In particular, there is no semver contract for release versions of this package. Please depend directly on individual versions.
See ast.dart for the in-memory IR, or binary.md for a description of the binary format. For now, the textual format is very ad-hoc and cannot be parsed back in.