- Use strong-mode types for more precise tree shaking.
- Bail out nicely if dart:mirrors is used.
- Run the tree shaker in the VM target.
The initial tree-shaking pass could be combined with the type checking
pass (inserting implicit down casts) but for now they remain separate.
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/2627723003 .
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 .
The redirecting factory List:: is currently removed and replaced with the actual target at the callsites during construction of kernel, but referencing the actual target here would make the transformation platform specific.
R=asgerf@google.com
Review-Url: https://codereview.chromium.org/2637083002 .
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 .
This CL brings us on-par with the VM implementation in terms of tests.
* Ensure we have saved-try-ctx/exception/stacktrace variables hoisted out for
try-catch **and** try-finally.
* Instead of closing the stream controller for 'async*' functions on return we
do it inside an try-finally block so we get there in terms of normal and
exceptional exit.
R=vegorov@google.com
Review-Url: https://codereview.chromium.org/2627873002 .
"Covariance checks" are checks on certain parameters, necessary due to
the unsafe covariant subtyping rule for interface types.
The new pass generates a checked entry point for each method with
covariance checks. This entry point checks the parameters whose type
cannot be trusted, and then calls the actual method implementation.
Every typed call is then redirected to the checked entry point if the
interface taget declares any parameters with unsafe types, unless the
receiver is 'this'.
Dynamic calls and covariant overrides are not addressed by this CL,
these are still unchecked.
BUG=
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/2618393002 .
Added offsets to more nodes.
Added end offsets to some nodes.
Added functionnode debuggability flag.
This changes the dill format.
The new offsets et al. are read on the C++ side, but not used
for anything usefull yet.
This is step #2 in introducing these things, next step(s) will be
using it on the C++ side.
R=asgerf@google.com
Review-Url: https://codereview.chromium.org/2626613002 .
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 .
Some of the kernel unit tests can now be run using:
tools/test.py -cdartk -rself_check language co19
This will search the pkg/ folder for files matching *_self_check.dart
and run each program with the compiled output as argument. If there is
no compiler, the test case itself is given as argument. These testers
are always run in batch-mode.
This type of test has no expected output, but is intended to check
itself by testing that certain invariants are not violated while
processing the given data set.
The 'self_check' runtime is not specifically tied to kernel,
although only kernel is using it at the moment.
There is also a new option --skip-compilation which skips the
compiler step. It doesn't interact nicely with the status files,
but can still be useful for a quick offline test.
Current limitations:
- All self-check tests are treated as the same test case. If one fails,
the remaining self-check testers don't run for that input.
- There is no way to run a subset of the self-check tests, or filter
them based on what compiler was used.
- Tests that are expected to fail in the compiler show up as
errors when skipping compilation.
BUG=
R=kustermann@google.com, whesse@google.com
Review-Url: https://codereview.chromium.org/2549793002 .
This is the result of:
- taking the diff of the branch closure_conversion to master in the kernel
repository
- updating the file paths
- applying the diff to the Dart SDK
- fixing conflicts between the changes to pkg/kernel in the Dart SDK and the master branch in the kernel repository
R=asgerf@google.com
Review-Url: https://codereview.chromium.org/2561723003 .
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 .
Peter von der Ahé