Kernel and Analyzer have slightly different rules for creating implicit
constructors, which DDC's kernel backend did not account for. This
resulted in a mismatch between which super constructor calls it thought
were necessary, vs which constructors were generated.
Both DDC backends are now less sensitive to the representations, and
the kernel backend checks for field initializers in mixin declarations,
rather than relying on the (nonexistent) implicit constructor node.
Change-Id: I01a6ae11ecf78193d7db227ba0b7adeb27d514d5
Reviewed-on: https://dart-review.googlesource.com/c/88432
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
It's simply an alias for `dartdevc --kernel`, and now that build_runner
is switching to that, there's no reason to keep it around anymore.
Change-Id: I43d30a582314a236bcfa2e3a0b50bb48ddac79f8
Reviewed-on: https://dart-review.googlesource.com/c/88281
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Vijay Menon <vsm@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
This improves the default JS display of exceptions/errors from DDC
compiled code. This gives a better "default" experience if JS code
(or a JS engine, like browers/Node.js) ends up catching Dart exceptions.
Change-Id: Ib2dda6eee710f8b536d5ed7223e0101310a137b3
Reviewed-on: https://dart-review.googlesource.com/c/84446
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
This uncovered a bug in dev_compiler that was showing up at compile
time--it was defaulting the enableAsserts flag to null, causing a null
pointer exception during kernel constant evaluation.
Change-Id: I2c75ffdc494f8d768aa98d67ef8257a20e74b9cd
Reviewed-on: https://dart-review.googlesource.com/c/86982
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The front_end code was sorting the summary URI list, which caused DDC to
find the wrong JS module import for a given summary (Components do not
store the URI they were loaded from, so DDC has to track that.)
Change-Id: Ief29c790d7303c8f290c6c669af2e1b34bc5bffb
Reviewed-on: https://dart-review.googlesource.com/c/84581
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Auto-Submit: Jenny Messerly <jmesserly@google.com>
This is similar to the analyzer backend's optimization for fields, but
it also supports private methods and accessors.
Also fixes#34769, checks were missing for explicit covariant fields
and those are now generated (this is for fields of the form
`covariant SomeType fieldName`--implicitly covariant fields in generic
classes were already checked correctly).
Change-Id: I5ce3ed7944bdc5a9799c731c5f95e199b461b079
Reviewed-on: https://dart-review.googlesource.com/c/79432
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Alan Knight <alanknight@google.com>
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Alan Knight <alanknight@google.com>
Original commit message:
[dartdevc] fix#35013, move DDC off Analyzer task model
The new file pkg/dev_compiler/lib/src/analyzer/driver.dart handles
building the linked summary for a build unit, and then is capable of
doing analysis using LibraryAnalyzer.
The algorithm is very similar to analyzer_cli's build mode. The
biggest difference is that `dartdevc` has existing support for
discovering source files from the explicit source list (rather than
requiring every source to be listed on the command line). We don't want
to break that support, so there's a bit of logic to follow imports,
exports, and parts.
After the linked summary is produced, DDC gets the analysis results
(errors and resolved AST) for each library, and compiles it into a JS
module.
Change-Id: I8d1855c27f9976cad6fd9ccb567b75a613e6048c
Reviewed-on: https://dart-review.googlesource.com/c/83060
Commit-Queue: Paul Berry <paulberry@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The new file pkg/dev_compiler/lib/src/analyzer/driver.dart handles
building the linked summary for a build unit, and then is capable of
doing analysis using LibraryAnalyzer.
The algorithm is very similar to analyzer_cli's build mode. The
biggest difference is that `dartdevc` has existing support for
discovering source files from the explicit source list (rather than
requiring every source to be listed on the command line). We don't want
to break that support, so there's a bit of logic to follow imports,
exports, and parts.
After the linked summary is produced, DDC gets the analysis results
(errors and resolved AST) for each library, and compiles it into a JS
module.
Change-Id: I7bf1ce1eca73fd036002e498de5924c488b534dc
Reviewed-on: https://dart-review.googlesource.com/c/82469
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Analyzer does not put mixin declarations in the `.types` getter, which
broke DDC's assumption that it contained all of the class/interface
types in the compilation unit. Kernel backend was not affected.
Change-Id: I219d814766fb97ef81920d0150cb1dfbbc6087f5
Reviewed-on: https://dart-review.googlesource.com/c/82022
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Alan Knight <alanknight@google.com>
Reviewed-by: Alan Knight <alanknight@google.com>
We're consolidating all dependencies on package:front_end in one file per tool.
The idea is, if you want to depend on something in the package:front_end, you
modify pkg/front_end/lib/src/api_unstable/ddc.dart and consult with the
front-end team.
These consolidated files will help us when designing a public API in the
future.
Change-Id: I505b8f986e8c2b1d93e158171c1ecc0c4e12b9a6
Reviewed-on: https://dart-review.googlesource.com/c/78220
Reviewed-by: Jens Johansen <jensj@google.com>
Dart for-in loops allow `var x = [1]; for (var x in x) {}`, which is not
allowed in JS. If this pattern is detected, a temporary variable is
introduced so the for-in initializer expression is evaluated outside of
the JS for-of loop.
(This issue seems to be unique to for-in loops. For loops and other
kinds of variable declarations of the form `var x = ...` are not
allowed to use `x` in the initializer, even if `x` is declared in an
outer scope.)
Also fixes an out-of-date comment in the DDC+Analyzer backend.
Change-Id: I35b272a5a311f7b6f104cc82a99cc83a6ed5c247
Reviewed-on: https://dart-review.googlesource.com/c/79142
Commit-Queue: Alan Knight <alanknight@google.com>
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Alan Knight <alanknight@google.com>
This regressed in https://dart-review.googlesource.com/c/74664/.
In Analyzer FunctionType.typeFormals returns TypeParameterElements
instead of TypeParameterTypes; it is not safe to assume non-null bound
for elements.
Also fixes & clarifies the intent of _canEmitTypeAtTopLevel (formerly
_typeIsLoaded). There was no reason to visit the typeFormals, as generic
function types can always be emitted into the module.
Change-Id: Ia8b9271c2d1b66dca934d032dcbbe4fe89146f1b
Reviewed-on: https://dart-review.googlesource.com/76746
Reviewed-by: Alan Knight <alanknight@google.com>
Allow super calls to occur in mixin declarations if they target a
method from any of the superclass constraint interfaces.
Instead of compiling the Dart mixin declaration
mixin M on S0, S1 {...}
to Kernel:
abstract class _M&S0&S1 = S0 with S1;
abstract class M extends _M&S0&S1 { ... }
we compile it to Kernel:
abstract class _M&S0&S1 implements S0, S1 {}
abstract class M extends _M&S0&S1 { ... }
because the former is not symmetrical with respect to S0 and S1. It
will prefer a method from the 'mixin' S1 over one from S0 which can
give a compile-time error if the method from S0 is more general.
Modify mixin inference to support the new compilation of mixin
declarations. It still has to support old-style VM super mixins until
support for those is removed from the VM.
Change-Id: Ib945aa11cc19c457b07bc802beae10d1663ff6b7
Reviewed-on: https://dart-review.googlesource.com/76141
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
`dartdevc --kernel` is now equivalent to the old `dartdevk` command.
This will make migration easier, as it's now just a flag to enable
CFE/Kernel. `dartdevk` is now deprecated, but it can be supported for
a while as it just calls `dartdevc --kernel`.
Change-Id: Ib8d09f74556740a3af11c753f80cd87bd4a09044
Reviewed-on: https://dart-review.googlesource.com/76566
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
This change expands typedefs into their underlying function type in the
compiler. Typedefs no longer exist at runtime in DDC, so they now have
similar equality and identity behavior as other function types.
The compiler used to preserve typedefs so they could have a better
toString. But over time that support has been almost entirely lost;
the caching for function/interface types eliminates typedefs, and
DDC+Kernel does not appear to get any TypedefTypes from the common
front end. So in practice typedef types were almost never present at
runtime. Because of this, we can remove the remaining support with very
little user visible effect. This also brings DDC's canonicalization
roughly in line with dart2js for compile-time typedefs, so frameworks
like Angular will be able to continue their use of `identical` for fast
type comparisons.
This CL also fixes DDC's type caching for generic function types
(typeHashCode was incorrect for them), and has some refactoring to
improve names/comments and make the SDK runtime code more clear.
Change-Id: I4e34c0c8f737a8535ba474a4683967ff41bcd3c8
Reviewed-on: https://dart-review.googlesource.com/74664
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Alan Knight <alanknight@google.com>
Fixes#34167. This implements the Dart 2 mixin proposal
(https://goo.gl/KEKQyv) for DDC. When the mixin is applied, a class
is created for the application that extends the correct superclass
and has all of the instance members, so `super` works correctly.
This also fixes a few minor issues in Analyzer's (mostly complete)
implementation:
- InterfaceType.isObject now returns false for Dart 2 mixins.
- Least upper bound calculation recognizes mixins are not Object.
- Interface of the mixin now implements its superclass constraints.
- Mixin superclass constraints are checked against the superclass and
all previously applied mixins (if any); this keeps it working with
the subtype fix above, and also prevents a not-yet-applied mixin
from satisfying the constraint
The language_2/mixin_declaration tests were updated with a few minor
fixes now that we can run Analyzer/dartdevc to test them.
This change implements super mixins for DDC's Kernel backend (DDK)
too. This will be enabled once Kernel adds a flag to recognize which
Class nodes are mixins (vs normal classes).
Change-Id: Ib3c4fcb12de9988345e52d92931196828d8227c3
Reviewed-on: https://dart-review.googlesource.com/74965
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
The canonicalization of symbols needs to take library privacy into
account. Since the Symbol class itself only has a [_name] field but does
not reference in which library the symbol came from, the [_name] must be
mangled.
Mangling is done by backends and so we make a new [SymbolConstant] which
the backends can desugar by doing appropriate mangling and construction
of a [Symbol] instance.
Fixes https://github.com/dart-lang/sdk/issues/34396
Change-Id: I2e13288483c35f875d39eefdb73677b2cc03527a
Reviewed-on: https://dart-review.googlesource.com/74360
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This allows dartdevk to be used in the context of an existing build
system based on Analyzer summary files. This will ease migration of
existing dartdevc users over to dartdevk.
Change-Id: I8413f906e384f3f33c98e450adc0860f6fa7bc53
Reviewed-on: https://dart-review.googlesource.com/65641
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
The canonicalization of symbols needs to take library privacy into
account. Since the Symbol class itself only has a [_name] field but does
not reference in which library the symbol came from, the [_name] must be
mangled.
Mangling is done by backends and so we make a new [SymbolConstant] which
the backends can desugar by doing appropriate mangling and construction
of a [Symbol] instance.
Fixes https://github.com/dart-lang/sdk/issues/34396
Change-Id: I5ddb5331ce79a0b942807929d4b8f1050a9899e7
Reviewed-on: https://dart-review.googlesource.com/73883
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
When dynamically calling a generic function or method without passing
any explicit type arguments, the default bounds are used. The default
should be `dynamic` unless an explicit bound was provided for the type
parameter.
Change-Id: I82f7166303f936adbecedd0c633b518f2700def4
Reviewed-on: https://dart-review.googlesource.com/72081
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
When the superclass has a getter/setter pair, and the subclass only
overrides one of the pair, DDC will generate the other one to forward
to the superclass. However these should not be generated for abstract
accessors. This patch fixes the compiler so it skips abstract accessors.
Change-Id: I60fa83b57db2e42ab47b7f4f3c28ef2a56e324ec
Reviewed-on: https://dart-review.googlesource.com/72073
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Jenny Messerly