Size of a large application:
Before: 26628600
After: 21480120 (-19.3%)
Size of snapshots:
isolate_snapshot_framework.bin
Before: 9322496
After: 6782976 (-27.2%)
isolate_snapshot_product_framework.bin
Before: 9166848
After: 6602752 (-27.9%)
Regressions in tests:
1) Test language_2/type_alias_equality_test/04 fails similarly to default mode, as VM
does not implement comparison of function types according to the specification.
Previously this test was passing as function types were canonicalized in bytecode,
which was not always correct. This CL fixes the problem with canonicalization of
function types in bytecode and the test starts failing again.
2) Tests standalone_2/entrypoints_verification_test, standalone_2/io/test_extension_test,
standalone_2/io/test_extension_fail_test fail as native extensions are not supported
in bytecode yet. These tests start passing after df5e7aac17,
which switched bytecode tests to kernel service (on x64), because kernel service doesn't
drop ASTs. This CL switches from reading AST library declarations to bytecode even if
AST is not removed, so tests fail again.
Change-Id: I8b7ba44bfa49d0b1599b2509553ff7c831a4e244
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104700
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Before this CL we could both crash and add wrong metadata to "part"
nodes when a part defined other parts.
This CL fixes it by
a) Not resetting a counter so *every* part in a part will be out of
bounds when trying to reference it; and
b) Check if a part directive is in bounds and ignore it if it isn't
(an error should already have been issued).
Change-Id: I3d31f2577b2120df6461c9cc1002131dbee9dbbc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/106641
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@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>
This removes one location where ErrorToken processing is no longer needed
in the parser, and updates the analyzer parser tests to use scanString
rather than instantiating the scanner directly.
Change-Id: I399d771004af7f9fe25d19c1065fbfd425416edc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105901
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@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>
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>
Before this CL, whenever a dill library builder was asked to compute
the outline it would finalize its exports - even if it was already done.
This is not really a problem (it mostly puts stuff into maps --- doing
it again will just overwrite what's already there with the same thing
again), but when having many dill library builders, and asking them to
compute the outline again and again because we've added a few new ones
(e.g. via kernel worker) it adds up to a lot of wasted time.
This CL adds a boolean to the dill library builders to avoid re-doing
this already done work.
An internal benchmark via kernel worker of lots of outline
calculations in worker mode with reuse and the incremental compiler
(and lots of dill loaded dependencies) goes from ~149 seconds to
~143 seconds.
Change-Id: I19cadbf64ff5e0ff117bad4df86c83832a1f28fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105243
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Kernel mode only
Build with:
> dart bin/dartdevc.dart -k --compile-sdk dart:core --modules amd -o dart_sdk.js
For now, this doesn't support building only parts of the SDK - dart:core brings everything in.
Change-Id: I23cda3064408778dc93c9b3d4be757f1e99bae0e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104811
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Vijay Menon <vsm@google.com>
Before this CL this code would crash fasta:
```
class A extends Function() {}
```
Now it produces a compile time error instead:
```
t.dart:1:7: Error: Can't use a function type as supertype.
class A extends Function() {}
^
```
(technically it already issued it, but crashed before doing so).
Bug: #36824
Change-Id: Iaeb9dc8390d4a9ab7b473848c3311f08a4dbba6d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101283
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@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>
For constant field initializers, compile the initializer expression
to Kernel, perform local type inference, and perform necessary
rewrites during outline construction. This will support constant
evaluation during separate compilation.
Change-Id: I65fe601595c04c45d586d0bac97c2ade6ab15a90
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104564
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
An internal benchmark via kernel worker of lots of outline
calculations in worker mode with reuse and the incremental compiler
(and lots of dill loaded dependencies) goes from ~160 seconds to ~150 seconds.
Change-Id: I80afa10caacef5e14e569928a1d421bd3e8ab342
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/104003
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Jens Johansen <jensj@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>
When the .packages file has changed we need to re-check all package-uris
to see if we need to invalidate the builders (if the file uri for a
package uri library (e.g. if the package was upgrade) has changed we
have to invalidate it).
This translation is semi-expensive though, so if we can avoid it that
would be a good thing.
This CL caches the "base URI" for packages from the previous run,
so we can start by comparing the base-URIs: If the base-uri for a
specific package hasn't changed, nor will the actual translation.
Only if the base uri has changed we do the actual translation,
and thus save many package-to-file-uri translations.
An internal benchmark via kernel worker of lots of outline
calculations in worker mode with reuse and the incremental compiler
(where the .packages file change every time and we have lots of
package-uri libraries) goes from ~185 seconds to ~162 seconds.
Change-Id: I3ed48b23a590dbf66f8a2379bb88e1b177f1f034
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103804
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Before this CL we removed from from the builders map, but left them in
the libraries list.
When using the incremental compiler via kernel worker (where we
continually replace dill builders) that meant that this list would just
keep growing.
This CL cleans it up and the builders map and the list should now be
in sync
An internal benchmark via kernel worker of lots of outline
calculations in worker mode with reuse and the incremental compiler
goes from ~215 seconds to ~185 seconds.
Change-Id: I254558d517f544fe31b5673e0dc8748048f0c5ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103630
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 includes:
* accepting null values like sdk-summary or .packages (which are not used when building kernel for the sdk itself)
* allow enabling language experiments
* only exclude-non-sources on the non-incremental code path if that's requested
Change-Id: I08eeb643676f1f1406f0f3030c341d68179d42a2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103574
Reviewed-by: Nate Bosch <nbosch@google.com>
This improves the missing class, mixin, and extension method body
error messages and lays the groundwork for improving other
missing body error messages such as switch statement, finally clause,
and others.
Change-Id: I0a4d1338fe91eee3cfe7d61652e168df1302d212
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103570
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Alexander Markov