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>
This CL removes the sources from uriToSource for libraries
the incremental compiler doesn't keep around.
This includes:
* Explicitly invalidated libraries, also if in a package.
* Transitively invalidated libraries, also if in a package.
* Libraries that are now no longer referenced in the resulting whole
program, unless it's in a package.
* Libraries from packages that are implicitly invalidated by an
updated .packages file (e.g. if the .packages file no longer
reference it or reference a new version of it).
This does *NOT* include:
* Libraries from packages that are not invalidated and that are still
mentioned in .packages, even if the actual libraries are no longer
referenced in the resulting whole program. The reason is that these
libraries are kept around in the incremental compiler.
Bug: 36197
Change-Id: I0ed41567ab54828585326ffd4dcb3722980bf874
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97201
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
For initializeFromComponent to work correctly the platform has to be
provided (as the other libraries provided are linked to some platform,
and loading another one is thus no good).
This CL changes it so we don't load another one, and checks that the
component we're trying to initialize from actually contains dart:core.
Change-Id: I88d30436c101c589b0555ff70ae21297ed665d7b
Reviewed-on: https://dart-review.googlesource.com/c/93435
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Without this CL the incremental compiler could potentially return too
few libraries (or possibly 0 libraries):
If the entry point is translated to a package-URI and there is no main,
the entry-library when doing the transitive closure cannot be found and the
output will be no libraries.
If the entry point is translated to a package-URI and there is a main,
the entry-library when doing the transitive clusire is only found because
of the otherwise unneeded `mainMethod` parametesr.
This CL adds tests and fixes the problem.
Change-Id: Icea72eb892cb0d16f0d86e3729e29ce026fa7073
Reviewed-on: https://dart-review.googlesource.com/c/92430
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Prior to this change, old problems (warnings, errors, etc) would not be
re-issued for files not actually recompiled when recompiling.
As an example, not making any change and recompiling it would seem like
everything was good.
With this change, all problems should be issued again.
Change-Id: Ia410edba27438d8a2f1842d9f4d81d0592571101
Reviewed-on: https://dart-review.googlesource.com/c/91747
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Fasta can generate synthetic libraries.
Previously we didn't include them when serializing, but that leaves
references in the binary to libraries that doesn't exist which isn't
ideal.
This change includes them, and adds a flag to kernel Libraries such that
we know they are synthetic.
Change-Id: Ied25a21cd1f384d318347021bc7ec18dae3a4e05
Reviewed-on: https://dart-review.googlesource.com/c/91722
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Prior to this change, problems issued in hierarchy.mixinInferrer could
be swallowed up because it was reported through a wrong loader that
had already issued the error.
Change-Id: Iecbc180ca8a0bfaa73db202e4cba9755812d1e3b
Reviewed-on: https://dart-review.googlesource.com/c/91746
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Get an error saying something like
"The argument type 'dart.core::String' can't be assigned to
the parameter type 'dart.core::String'"
Change-Id: I327c613a2070495653e4089475a4f3edf550e9d4
Reviewed-on: https://dart-review.googlesource.com/c/91228
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Previously we had several places where different uriToSource was used.
This was both weird and led to errors when something refering to
some state was used to look up in another state.
This CL makes it so we only have one source of truth.
To not include sdk sources when serializing a component that only mixes
something from the sdk in, (or extends it or...), the serialization is
changed slightly to keep track of which uris come from actual
implementation. Before the sdk sources was explicitly removed in the
incremental compiler, but we want to limit those kinds of things,
which is why we're doing it differently here.
Fixes#35215.
Bug: 35215
Change-Id: Iaa5618fcb0ea42b13aba7720f34a87a85144e047
Reviewed-on: https://dart-review.googlesource.com/c/85175
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
In the incremental compiler, if asking to invalidate a file via a file
uri, where the corresponding file is a part that has been used via its
package uri (as in "part 'package:foo/whatever.dart'"), we should still
invalidate it.
Before we didn't because we 'translated' the part uri to a 'file uri'
except it was still a package uri.
Now we do.
Change-Id: I276c6e7c772d6167178fa8b6594417d37d1dd1c4
Reviewed-on: https://dart-review.googlesource.com/c/85344
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@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>
Before this CL, if initializing from a dill file containing a class,
say A, but it wasn't used, and then later using it as a type, say
'A a = new A()', the class hierarchy would complain about not knowing A.
This was caused by the class hierarchy initially being constructed using
the full component of the first compile (i.e. in the example above
without any usage of A and thus without including A), and subsequent
compiles telling the class hierarchy about new classes created in that
compile. The problem was, that if the class was loaded from a dill file
(in the example above 'A' was such a class) it would never be included
if not a part of the first full component.
This CL fixes it by changing the interface to the class hierarchys
`applyTreeChanges` function and letting the class hierarchy know about
libraries too: It will now basically just be given the full component
when asked to update, and just update with the libraries it doesn't
already know about. In the example above that would - once using 'A' -
include 'A'.
Change-Id: I895100b51659938636da0bca6c80516d87b57a24
Reviewed-on: https://dart-review.googlesource.com/69302
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Before this CL, the invalidated URLs would be cleared sooner than we
threw away the old "userCode".
On a compile time error (issuing an erroneousComponent) we restore
the old userCode, thus in practical terms forgetting about whatever
had been invalidated prior to that.
This CL introduces a test and fixes the problem.
Change-Id: I8f5329c2f499ec3842d0b7d67e2eda1de1e7d938
Reviewed-on: https://dart-review.googlesource.com/52321
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
In a86b864fa9 the incremental compiler was
updated to always bypass the cache when getting a UrlTranslator to be
able to handle the case where .packages had been updated.
This was driven by Flutter not invalidating .packages.
This has now been introduced in flutter with
https://github.com/flutter/flutter/pull/16467
and we can now limit when we bypass the cache to when the .packages file
has been invalidated.
This CL does just that, and further more adds tests where .packages either
appears or disappears.
Change-Id: I3e2d001a993a59c115bc00fcf714f97094357d35
Reviewed-on: https://dart-review.googlesource.com/50940
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Prior to this CL a builder loaded from a dill file - but where the
file has now been deleted (and we've previously been told about it) -
was kept around, meaning that it could get resurrected in a later
call to computeDelta.
This CL introduces a test and fixes the problem.
Change-Id: Ia18639a1387b37f8d641f803f202288dd185af5c
Reviewed-on: https://dart-review.googlesource.com/50722
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Before this CL, if initializing from a dill file, and then,
at a subsequent call to computeDelta asks for the full Component,
the sources from the originally loaded libraries was missing.
This also meant that some fileUris were missing.
This can basically break Flutter.
This CL introduces tests that catch this, fixes the issue and bumps the
kernel version to force recompilation in Flutter.
Change-Id: I9f62962db017cec232855377835103ffc324820b
Reviewed-on: https://dart-review.googlesource.com/49642
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL addresses comments from previous CLs, renaming variables and
handles change package versions.
Change-Id: I83cf4a33bffe82ec137a32710cd6e8ff7f25ec8b
Reviewed-on: https://dart-review.googlesource.com/49161
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL follows up on a previous CL, renaming "simple tests" to
"basic tests" and gets rid of names in tests, as they no longer matter.
Change-Id: Id66368f26f8e2e36a8034d237f1708b30562de86
Reviewed-on: https://dart-review.googlesource.com/49160
Reviewed-by: Peter von der Ahé <ahe@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
When incrementally compiling, we can have builders for things that aren't
included anymore. Such builders should not introduce errors.
Change-Id: Ia0487d84819028913d54f6b55a2882e620009bd9
Reviewed-on: https://dart-review.googlesource.com/47223
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Prior to this CL, if loading a library from the dill file what ends
up being unused in the new program it would still be included in the
output. This CL introduces a test and fixes the problem.
Change-Id: I60dd9c3b6bdb959e103f0d2a5653d036b6653140
Reviewed-on: https://dart-review.googlesource.com/46983
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Prior to this CL, if incrementally compiling something and the .packages
file changed we could get a crash when trying to translate a package url.
This CL introduces a test and fixes the problem.
Change-Id: Ie1874780df7ade394eecef05835b0d9203f4c2b5
Reviewed-on: https://dart-review.googlesource.com/46982
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Split into 2:
- One with a "smoke-test" of dart2js.
- One with several small examples that has caused problems in the past.
The latter of the two is now based on package:testing and the test-cases
are saved as yaml files.
Change-Id: I8b588e9b42edc73f58a07292a1226e37cc458d89
Reviewed-on: https://dart-review.googlesource.com/45505
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Jens Johansen