We no longer need the distinction between *Generator and Kernel*Generator
so the Kernel*Generator classes are now merge into the *Generator classes.
Change-Id: I9f9650fc4ab88a0952b8d2bd346e1d416d68eac6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/109707
Reviewed-by: Dan Rubel <danrubel@google.com>
To insert covariant checks, CFE was searching for covariance in
contravariant positions and _not_ for non-covariant
(=contravariant+invariant) positions of type parameters. This
let to the omission of needed checks when type parameteres were
used in invariant positions (in function type parameter bounds).
Closes#37476
Change-Id: Icb4a827e75aee1a679ef7175d36904bbfbf6aa0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108815
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
The objective of this CL is to allow the incremental compiler to track
which dill input libraries it actually used (in order to - in a modular
context - be able to ignore changes to dependencies we didn't really
use).
This is done by:
* Making the dill library builder lazy (and mark if it has been used).
* Making kernels class hierarchy record which classes it has been
asked questions about.
* Add special handling to redirecting factory constructors as they
bypass the fasta-builders and directly use the kernel ast.
Please note that:
* This has to be enabled, but kernels class hierarchy always records
which classes it was asked about (even if disabled,
or not running though the incremental compiler).
There might potentially be some overhead to this (though setting
a bool to true is probably comparably cheap - we did just do a
map lookup).
* This was designed to be used together with modules
(e.g. setModulesToLoadOnNextComputeDelta) - as used via for instance
api_unstable/bazel_worker.dart. It might not function the way you'd
expect in other circumstances.
* The incremental compiler (potentially) gives you the full kernel tree
despite not having marked all of those libraries as 'used'. If a
client use such libraries it is the clients responsibility to take
that into account when answering any questions about this
libraries/dill files was used.
* This feature works on the library level. In practice it is most likely
needed at the dill-filename level. A translation from library to
dill-filename is up to the client.
* This is a new feature, and we cannot promise that 100% of actually
used libraries are marked. If you find used but un-marked libraries
please report a bug.
Change-Id: I01d7ff95b9baac9550b77d8e09ea772d43173641
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107280
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
- Pass empty environment defines into CompilerOptions - to ensure that
there are no unevaluated constants in the output. VM does not expect
those.
- Include constant table when comparing expectations
Change-Id: I276e8bf8ce1f4f39c63265e4ae2650953649e41f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108800
Auto-Submit: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
CFE failed to replace an invalid AwaitExpression in a non-async context
with an InvalidExpression. The lead to untransformed (and thus unexpected)
await expressions crashing the hot reload.
Closes#37108
Change-Id: I4457925b20749d231cbf9dac80203ee9b381a312
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107501
Reviewed-by: Dan Rubel <danrubel@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Update the message_test to automatically create an example that wrappes
all already defined examples in a part.
For instance, if the example is
main.dart: main() { print("hello world"); }
create an additional example that is basically
main_wrapped.dart: part 'main.dart';
main.dart: part of 'main_wrapped.dart'; main() { print("hello world"); }
(as well as some additional comments to push any actual positions in the
main file ot of scope for valid positions in the wrapper file.
This doesn't work for everything, e.g. if the original main imports or
exports anything, the new test will fail. That's okay, the status file
has been updated accordingly.
The reason for adding it is that we currently have some bugs that causes
us to crash in situations like this, i.e. situations where a message is
coming from a position in a part where the same position doesn't exist
in the non-part file.
The status file has been updated for that too, although not in sorted order.
Change-Id: Ib67f85fca5e81e0b9e93cf2d79ab50c38cae4936
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/106082
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Eventually it should be handled by Procedure.isRedirectingFactoryConstructor, but that is
currently broken for patch files.
It appears the VM has no patches of that kind, but dart2js does.
Change-Id: I0b64379f16089ad0d98ecd4df1ed9282ed6bc0e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98523
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Prior to this CL, we would issue a warning whenever a CanonicalNameError
was encountered.
This is in principal a good thing, but because we currently have no way
to detect if the sdk we get is the one we expect
(by any other measure than when it issues a CanonicalNameError) we often
issue these warnings for no "real reason" whenever, for instance,
the flutter sdk changes.
This CL splits the CanonicalNameError in two such that errors with
references to the sdk ("dart:" libraries) issue CanonicalNameSdkError
instead, an we then handle that differently. Namely we silently ignore
the error (i.e. don't issue a warning) and just don't initialize from
dill.
This should remedy the situation and be strictly better than to always
swallow CanonicalNameErrors.
Bug: 36032
Change-Id: Idbae0b5ee5b9843a5dbeb49b3c65ae25f5962e36
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105240
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This was a left-over from when unbinding, and should no longer be needed.
An internal benchmark of lots of outline calculations in worker mode with
reuse and the incremental compiler goes from ~248 seconds to ~215 seconds.
Change-Id: Iedb6a3fb11504610c061503efb741e35919f0d32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103629
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This CL revises the scanner API so that tokens are always prepended
to the beginning of the token stream. This allows the parser handling
of error tokens to be simplified. Any clients using the scanner directly
rather than through the scanner API should call scannerRecovery
if the scanner has detected errors in the content.
Change-Id: I32510da10205bd964f80898a238489d1508733e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/102680
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
This CL is the next step in moving the language version comment
detecting from parser to scanner.
* update the scanner to produce a new LanguageVersionToken
* expose the languageVersion in the scanner result
* include languageVersion as a comment if includeComments == true
* rename languageVersionToken to languageVersion
Change-Id: Ie6be6e95e2fa6b7d3b9123bea556bcd5e89888f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/100880
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
If an expression compilation issues problems of any sort, they are saved
in the target-libraries problemsAsJson field. That's not ideal,
as it means that they can be re-issued later, as well as possibly being
serialized into the dill file.
This CL resets the problemsAsJson field of the real library,
thus fixing the issue.
Change-Id: I765c2cc50059c6bcda6a56bb749869dd4b181876
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96800
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
TL;DR: Unbind canonical names doesn't do what you think it does and
probably shouldn't (ever) be used. This CL stops using it in a few places.
Longer version:
When loading a dill file it:
- First loads the table of canonical names. These have no references yet.
- When a canonical name is asked for its reference it creates one if it
doesn't yet have one.
- When loading, for instance, a library, it asks for the reference.
When unbinding a canonical name:
- It removes itself (the canonical name) from the reference
- It removes the reference in itself
- Note: Whatever has a pointer to the reference keeps it, and the
reference points to whatever node it already pointed to.
This also means, that if we have a dill file that's split in two and:
- Load #1
- Load #2
that works fine, but if we
- Load #1
- Unbind canonical names
- Binds canonical names
- Load #2
stuff is not bound correctly (and an error is thrown).
And - the cause of this bug:
- Load #1
- Load #2
everything is fine
- Unbind canonical names
- Binds canonical names
- Load #2'
stuff is not bound correctly --- references points to stuff loaded as #2,
not as #2'. On top of being weird, wrong and confusing it also caused wrong
things to be but into the class hierarchy which ultimatly caused the crash.
This CL fixes it by not calling unbind and force loading of dill files
(at specific call sites) to create new libraries
(and in the process overwriting references ".node").
Revert "[dartdevc] Retry ddc incremental compile on crash"
This reverts commit ecdbdf00b8.
Revert "[kernel_worker] retry on failure"
This reverts commit 43eebea5a3.
Fixes#36644
Bug: #36644
Change-Id: Id8f548179e6a409b01f2ebfa3219f94cb64b1c05
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/100380
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
When performing top-level type inference based on overrides for fields
that have initializers, we never perform type inference for the
initializers. Since type inference is the thing that rewrites shadow
AST nodes with their Kernel translation, we are left with
untransformed shadow nodes that cannot be serialized.
Instead, remove these initializers. Fixes
https://github.com/dart-lang/sdk/issues/36498
Change-Id: I044fadd897e9f2d0e37f5ce0e5adaadb0e42a992
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99120
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Johnni Winther