When we perform constant evaluation in the CFE, the async transform
runs after constant evaluation. Thus, it can no longer use const
bool.fromEnvironment("dart.vm.product") to query whether the VM is
in product mode.
Instead, it can read the product mode define directly from the
environment defines given to the CFE and generate different code
depending on the value.
Change-Id: I2aabc4a84b50a940d35d5664ff4ebdf0680ed5c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111645
Reviewed-by: Johnni Winther <johnniwinther@google.com>
A kernel library will say it has the newest language version if no
language version is set.
This basically preserves the current semantics of always being on the
newest version (if nothing is explicitly done), e.g. if creating a kernel
library by hand and not setting it.
The front_end also utilize this and just doesn't set it, if it isn't set.
Change-Id: I033fef13626ee034030ba8fc9d141b182ba1a5ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111739
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL sets up the bare minimum support for saving the language version
specified in a file on the kernel library, and adds simple support for
testing it.
The data is not serialized out, error checked or similar in this change.
Change-Id: I4b061ce617acae7964b85be105e0ad0e3e031aa4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111640
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Programmers can use nullability modifiers on type parameters when using
them as types. However, the actual nullability of such types is
calculated from that and also from the bound of the type parameter, and
from the promoted bound if it has it. Previously, the final result of
the nullability calculation was stored on the type. This CL also stores
the nullability declared by the programmer.
Change-Id: Iabbddc1e8a477678975190fa00bf702c914f7777
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/111424
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
The many different entrypoints to the CFE have repeatedly shown problems
with targets that do not support unevaluated constants being used
without providing an environment.
Making the targets opt-in to supporting unevaluated constants will
give the users of CFE early notice that CFE is used inconsistently
(as opposed to the backends failing when they happen to see an
UnevaluatedConstant node that they don't support).
Change-Id: I98c80df3a551823598e413e2895f5649f22f7c22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/110561
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This allows us to use ui-as-code and set literal features in these
packages.
This should be safe because (a) when these packages are used within
the SDK itself, they are used with the most recent SDK (whose version
is greater than 2.2.2), and (b) the only significant dependency on
these packages in pub is from the analyzer, which already has a
minimum SDK version of 2.2.2.
Change-Id: I4f7d4c9506904ee3016db95297b45e5bcf7989b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/110060
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@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>
Make sure to use Printer methods when formatting class references
instead of going through TreeNode.toString which uses globalNames
instead of Printer's own syntheticNames.
Change-Id: I3107a1b4d5d6d2b26a9f0001f846bd74b85853df
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108803
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Auto-Submit: Vyacheslav Egorov <vegorov@google.com>
During constant evaluation, unused arguments to a const constructor are
thrown away after evaluation, since their values do not affect the
resulting instance constant. If such an unused argument ends up
unevaluated, any errors that would arise in the final evaluation are
not reported.
This CL adds space in the Kernel AST for saving these unevaluated
expressions so they can be checked during final constant evaluation.
Even though this is an incompatible change, no update is needed to the
VM code (except for the version bump), since the VM does not support
InstanceCreation nodes in the first place.
Change-Id: I4752562c1164efbba79eb018c15b07ed8354ce5f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105761
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Aske Simon Christensen <askesc@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>
During the outline phase, after top-level type inference, compile
annotations for libraries, classes, fields, procedures, and
constructors.
Change-Id: I95ca65fd58ad88d9452a28d5a0652bee44aeda3a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103806
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
We shouldn't crash and reporting something as being on line 1 of a file
because we don't know where in the file it is, doesn't seem right.
Change-Id: Ia8d6145e21a136903771d876633036b292ea12ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/100842
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@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>
Using path dependencies here is misleading - they are not sufficient for a
`pub get` and we do not expect to do a pub solve in this package. In order to
suppress the warnings on `pub publish` we need only the `any` dependencies and
can rely on the repo's `.packages` file to resolve their path.
Change-Id: I5e7b2d50ece2c133b2583fd75eab3509db400a95
Bug: 36581
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99204
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
This for instance allows the VM to include all patches
(e.g. the previously missing `runtime/lib/date_patch.dart`)
in what's returned from `LoadedScripts()`.
Over time this also allows for `LoadedScripts()` to be simplified and
become faster (it's currently something like O(m + m*n) where m is the
number of results in DictionaryIterator(*this) and n is the number of
returned scripts).
Change-Id: I4b5a6a0fe666b774fc0987d099ed02e81ac97b43
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98660
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Before a import of, say "hello.dart" was printed as
"import './hello.dart'".
Now instead it is printed as "import 'hello.dart'".
At the same time we get rid of a dependency.
Change-Id: I352f0f507168fde75358704ec9bf0e248bb8179d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98480
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Dmitry Stefantsov