Summary:
Previously, we filled in all occurrences of captured type variables with either
"dynamic" or their bound, if they had one.
Now, we add extra type parameters to the top-level function corresponding to the
closure, and pass in the corresponding arguments as type arguments to the
"MakeClosure" operation.
Test Plan:
Updated [type_variables.dart] and added a new test case to it.
R=dmitryas@google.com
Review-Url: https://codereview.chromium.org/2989563002 .
It is informative in the same way as documentation.
Yesterday I tried to make Analyzer and Analysis Server stop using
FieldFormalParameterElement(s) and found one important use case requested
by the Flutter team. We need to show documentation of a field when
user requests documentation on the corresponding field formal named
parameter. This happens outside of the file that declares the parameter
and the field, so we don't have AST available. Of course we could
resolve the unit, but it would cost us something. And if we decide
that it is OK, then maybe we don't need to have documenation comments
in elements at all.
This is of course more convenience, and we could store documentation
and parameter to field mappings outside, like we store index. Just a
compromise - convenience vs. purity.
R=ahe@google.com, kmillikin@google.com, paulberry@google.com, sigmund@google.com
BUG=
Review-Url: https://codereview.chromium.org/2983173002 .
This mimics the behaviour of the source-based pipeline,
i.e. instead of "manually" calling _AssertionError._create and giving
the correct parameters (wrong parameters, actually), use the helper
method _AssertionError.ThrowNew.
BUG=
R=ahe@google.com, vegorov@google.com
Review-Url: https://codereview.chromium.org/2940283002 .
This adds support for cloning the following kernel AST nodes.
* ClosureCreation
* VectorCreation
* VectorSet
* VectorGet
* VectorCopy
This will be needed for kernel closure conversion.
BUG=
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/2874973004 .
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 .
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 .
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 .
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 .
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 .
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 .
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 .
This makes super calls name-based (no target) and add direct calls with
both receiver and explicit target.
Super call resolution translates the name-based super calls into direct
calls after they have been cloned into the mixin application.
For JS backends, it should suffice to clone mixed-in methods that
contain super calls, but that transformation is not part of this CL.
This also adds a --target option to dartk designating the target to
which the kernel IR should be specialized. The new transformation
is run when --target=vm.
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/486537013 .
Paul Berry