commit | a9f684e62499e669294a07c3ce7d2aa7c545760a | [log] [tgz] |
---|---|---|
author | Jens Johansen <jensj@google.com> | Mon Apr 22 14:08:20 2024 +0000 |
committer | Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Apr 22 14:08:20 2024 +0000 |
tree | 63b82443760a14ca9836e4970cbc5e7f3a256b9b | |
parent | 387a094cdd7a6cbc8da73449d9f0955f21b4de4d [diff] |
[CFE/kernel/VM] Fix for crash when compiling after a reject in face of unnamed extension In https://dartbug.com/55357 a crash is reported happening after a hot restart (not reload!) with a compilation error. This causes a "reject" call, which means we create a new incremental compiler, initializing it from the component of the previous good world. World 1: Initial state. World 2: The library is new, but (most) references are reused because of advanced invaidation. References of unnamed extensions are not reused. Instead the canonical names are unbound (so they can successfully be bound to the new reference). We now have: * ref1 (from world1) pointing to no canonical name. * ref2 (from world2) pointing to the canonical name. * The canonical name pointing to ref2. This world is rejected. World 3: We start from the world 1 state, but because world 2 *did* happen and that only most references (i.e. not references for unnamed extensions) were reused, when about to unbind the unnamed extenesion we are looking at ref1 and have nothing to unbind. Compiling creates ref3 (from world 3). Upon attempt to serialize we try to bind the canonical name to "ref3", but it is already bound to "ref2" and we crash. The main problem here is that not only `Reference`s are reused, but because `Reference`s point to `CanonicalName`s these are reused too. This CL clears the canonical name in the references in the libraries that are reused, meaning that a whole new canonical name tree for those libraries will be created. This is more in line with what the non-advanced-invalidation does (by it not reusing references and naturally getting a whole new canonical name tree). In my opinion it even makes more sense --- and the fact that the canonical names were reused was probably more me not thinking about it, than it was a deliberate design decision. Fixes https://github.com/dart-lang/sdk/issues/55357 Change-Id: I90bd579984f4aefad78243e8366ac0ab91a905bf Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363563 Commit-Queue: Jens Johansen <jensj@google.com> Reviewed-by: Johnni Winther <johnniwinther@google.com>
Dart is:
Approachable: Develop with a strongly typed programming language that is consistent, concise, and offers modern language features like null safety and patterns.
Portable: Compile to ARM, x64, or RISC-V machine code for mobile, desktop, and backend. Compile to JavaScript or WebAssembly for the web.
Productive: Make changes iteratively: use hot reload to see the result instantly in your running app. Diagnose app issues using DevTools.
Dart's flexible compiler technology lets you run Dart code in different ways, depending on your target platform and goals:
Dart Native: For programs targeting devices (mobile, desktop, server, and more), Dart Native includes both a Dart VM with JIT (just-in-time) compilation and an AOT (ahead-of-time) compiler for producing machine code.
Dart Web: For programs targeting the web, Dart Web includes both a development time compiler (dartdevc) and a production time compiler (dart2js).
Dart is free and open source.
See LICENSE and PATENT_GRANT.
Visit dart.dev to learn more about the language, tools, and to find codelabs.
Browse pub.dev for more packages and libraries contributed by the community and the Dart team.
Our API reference documentation is published at api.dart.dev, based on the stable release. (We also publish docs from our beta and dev channels, as well as from the primary development branch).
If you want to build Dart yourself, here is a guide to getting the source, preparing your machine to build the SDK, and building.
There are more documents on our wiki.
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.
Future plans for Dart are included in the combined Dart and Flutter roadmap on the Flutter wiki.