This CL moves many of the files from
pkg/front_end/lib/src/fasta/analyzer/ to pkg/analyzer/lib/src/fasta/.
It also moves two files from pkg/kernel/lib/analyzer/ to
pkg/analyzer/lib/src/kernel/.
This reduces the amount of circularity between analyzer and
front_end/kernel so that there are no files in front_end or kernel
which are both dependend upon by analyzer and depend upon analyzer. I
will clean up the remaining circularities in future CLs.
There should be no functional change.
R=ahe@google.com, asgerf@google.com, kmillikin@google.com, scheglov@google.com, sigmund@google.com
Review-Url: https://codereview.chromium.org/2756593004 .
- Offsets on more stuff
- Status file for kernel
-> Testing with (before fasta)
```
python tools/test.py -mrelease -cdartk --no-tree-shake --no-dfe service
```
now shows everything as passing.
Reload stuff, and evaluation stuff (e.g.) has been disabled though.
- Lots of new service tests that tests what positions we stop at when
saying next.
As fasta has now landed debugging does not currently work, but this is still needed in order to both test better and allow for proper kernel debugging support.
R=hausner@google.com, kmillikin@google.com
Review-Url: https://codereview.chromium.org/2680303002 .
This adds a class CanonicalName that can represent a library, class,
or member. All references now go through a Reference object, which is
linked to both the AST node and its CanonicalName, so either can be
created first.
dartk now accepts multiple input files:
- If multiple dart files are given, they are all compiled.
- If multiple binaries are given, they are linked together.
Mixed dart and binary input is not supported by dartk.
dartk now has a flag --include-sdk which includes the entire SDK in
the output. This is so the SDK can be compiled alone and then linked.
Example of compiling separately and then linking:
dartk foo.dart -o foo.dill
dartk main.dart -o main.dill
dartk --include-sdk -o sdk.dill
dartk main.dill foo.dill sdk.dill --target=vm --link -o program.dill
dartk still has incredibly slow cold start due to the analyzer loading
the dart sdk, so this does not actually speed things up at the moment.
BUG=
R=ahe@google.com, kmillikin@google.com, kustermann@google.com, sigmund@google.com
Review-Url: https://codereview.chromium.org/2665723002 .
- The interface for a factory constructor in an external library would
reference the class type parameters instead of its own.
- When a class from an external library gets promoted to mixin level,
the rest of the library should not be considered "being loaded".
This would cause members to not get added to the AST.
BUG=
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/2710783004 .
Previously a functions debuggable field was set to false in the async transformation (and because it wasn't done yet, not in async* and sync* transformation, though it should have been). Now instead, set the original async status and set debuggable on the c++ side equivalently.
Also, on the c++ side, set a functions modifier to async etc if they were originally async etc.
BUG=
R=asgerf@google.com, kmillikin@google.com, kustermann@google.com
Review-Url: https://codereview.chromium.org/2697193008 .
When a class from a different build unit is mixed in, the instance
members of the mixed-in class are retained in the external library
definition, so the mixin resolution pass can clone them.
BUG=
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/2669303002 .
The test was incorrect because it did not declare that a static warning
was to be expected due to an unresolved reference to 'q'. The unresolved
reference has been removed as it has nothing to do with what it is
supposed to test.
The analyzer was incorrect in that a setter was reported to clash with
a constructor of the same name, but this failure was hidden by the
above issue. This has been fixed.
dartk inherited the issue (and its fix) from the analyzer, but some
additional error handling was needed in dartk to avoid crashing.
Closes https://github.com/dart-lang/sdk/issues/11576
BUG=
R=kmillikin@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2643693002 .
The CL adds metadata support for Fields/Classes/Functions/Constructors. There
are other places where annotations can be put in the Dart language but the
Kernel IR currently does not store it in the AST.
Whenever a element (e.g. a function) gets annotated, the VM will make a [Field] for this
element whos value is an array of evaluated constant metadata annotations.
This CL attaches to these [Fields] a `kernel_function` which is then used to do the constant
evaluation.
R=vegorov@google.com
Review-Url: https://codereview.chromium.org/2632253002 .
This implementation is based on the existing kernel and analysis
driver logic, using proxy classes to account for interface
incompatibilities between those components. In future CLs, I
hope we can (a) move the necessary analysis driver logic into
front_end, and (b) reduce or eliminate the number of proxy
classes needed.
This CL represents the very first inklings of functionality; all that
is confirmed to work at this point is compilation of a single source
file containing an empty `main` method.
R=danrubel@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2624193003 .
Updates to kernel that sets more offsets (and introduces end offests
and 'debuggability') - but doesn't necessarily persist them,
i.e. the format doesn't change and no C++ changes are neccessary yet.
This is step #1 in introducing these things, next step(s) will be
persisting the new stuff and using it on the C++ side.
R=asgerf@google.com, kmillikin@google.com
Review-Url: https://codereview.chromium.org/2610133002 .
- For now include source uncompressed.
- When running from kernel, use token position 0
(i.e. dummy, but 'real' position) as start and end on functions
and classes to enable Observatory to run with the dill file.
- Debugging does not work, but one can browse the source in
Observatory.
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/2587673004 .
TypeAnnotationBuilder and InterfaceType were being allocated
a bit aggressively.
It makes no measurable difference on runtime, but it rules out
some of these objects as potential culprits.
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/2581693002 .
This CL adds support for using sdk summaries when building kernel using the
front_end entrypoint. I didn't expose this functionality in the dartk binary,
I'm hoping we can delay doing so until we integrate dartk and front_end.
I also switched front_end/tool/perf.dart to use kernel_generator directly.
This makes some observable difference for small scripts, but not so much with large apps like dart2js. Makes sense considering that the sdk is about 2Mb, and dart2js is 6Mb of sources.
The most interesting number I got is building the a library kernel file (not the whole program) for a small hello-world script on a warmed up vm:
no summaries: 500ms
with summaries: 30ms
R=asgerf@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2562923002 .
This CL creates top level accessor functions which may be used to map from AST data structures to their corresponding elements and types, and begins using those accessor functions throughout the SDK. It also adds empty interfaces ResolutionTarget and ResolutionType, which are implemented by Element and DartType respectively.
In a future CL, I will change the types stored in the AST to ResolutionTarget and ResolutionType, rather than specific element types; this will decouple the ASTs from the element model. The presence of the accessor functions will allow clients to continue accessing elements and types in a type-safe way.
R=asgerf@google.com, brianwilkerson@google.com, scheglov@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/2551023005 .
As a result, this changes the order in which declarations appear in the generated output. The new order is more consistent with the textual order in the original file.
Calling .computeNode() is sort of an anti-pattern for using analyzer. This was
however used very sparsely in dartk. The few places where it was used,
computeNode was practically called immediately after resolving the library
element, so I don't expect this to make almost any difference in performance.
R=asgerf@google.com, paulberry@google.com
Review URL: https://codereview.chromium.org/2553303002 .
In kernel, library import URIs now support an "app" scheme as an
alternative to the "file" scheme, representing a path relative to
the application root.
dartk takes an --app-root flag giving the application root. If none
is given, file URIs are used instead.
The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.
It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.
In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.
Source mapping URIs are not yet affected by this change.
R=kmillikin@google.com
Committed: https://github.com/dart-lang/sdk/commit/60adb852ad706ecf9424c77d47fa05583d543def
Review URL: https://codereview.chromium.org/2532053005 .
Reverted: https://github.com/dart-lang/sdk/commit/bb540416f27c39d75ee7f243899939fc37a2cd03
In kernel, library import URIs now have the "app" scheme instead of
the "file" scheme, representing a path relative to the application root.
dartk takes an --app-root flag giving the application root. This
defaults to the current working directory.
The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.
It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.
In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.
Source mapping URIs are not yet affected by this change.
R=kmillikin@google.com
Review URL: https://codereview.chromium.org/2532053005 .
This was originally done to be consistent with FunctionType,
where the named parameters are sorted, but for FunctionNode
it is not necessary.
It causes issues for natives that expect parameters to be
declared in a certain order. It is also an issue if we
ever want to reuse the kernel format for summaries, where
it is also preferable to present the named parameters in
their original order.
BUG=
R=kmillikin@google.com
Review URL: https://codereview.chromium.org/2527933002 .
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 .
Previously, the type of a conditional expression could be omitted if
one of the arms was just a null literal. This was meant to simplify
translation into kernel, but wasn't really worth it in terms of
complexity, and it does not work well for types that carry nullability
information.
BUG=
R=ahe@google.com
Review URL: https://codereview.chromium.org/2465263002 .
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 .
That is, if a field has no declaration-site initializer and at least
one constructor in the class does not initialize it, then we add an
explicit null initializer for it.
BUG=
R=ahe@google.com
Review URL: https://chromereviews.googleplex.com/527827014 .
Previously, we would generate a stub for a redirecting factory, but
the default parameter values were not correctly forwarded.
This could have been fixed by copying the default parameter values into
the stub, but this conflicts with modular compilation, since the
element model does not expose default parameter values, and we should
not rely on the AST of libraries not part of the current build unit.
Apart from fixing this bug, this is also more aligned with how all the
backends actually work.
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/513577013 .
A mixin application C<T1 ... Tm> with D<T1 ... Tn> is canonicalized if
the Ts are distinct, unbound type variables. In all other cases, a new
class is created per mixin application.
Previously, all mixin applications were canonicalized in an overly
general way, causing type checking issues, and excessive duplication of
type parameters.
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/511567015 .
The VM does not support function type parameters at the moment, but we
can erase them at the last minute, to enable testing of other parts of
strong mode.
This also disables error checking in the SDK since the VM's
patch files are not in strong mode.
BUG=
R=kustermann@google.com
Review URL: https://chromereviews.googleplex.com/518647013 .
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 .
For now the focus is on getting stacktraces to look right.
What that basically means is to include source positions for throws,
calls (in many forms).
Includes source file uri for libraries, field, classes and methods.
Methods and fields for instance needs it because of top-level
procedures that might be included via 'parts'.
Corresponding kernel-sdk change in review at
https://chromereviews.googleplex.com/516617014R=asgerf@google.com, kasperl@google.com
Review URL: https://chromereviews.googleplex.com/509247013 .
Paul Berry