This CL makes experimental invalidation work on DillLibraryBuilders,
and solves all found issues (e.g. old references (aka leaks)) with it.
Note: This CL introduces a few writes that seems weird (e.g. setting
variables that's about to be out-of-scope to null). This is done to
prevent "leaks", or probably more likely, prevent a "false positive"
leak detection and it currently gives a "clean bill of health" from
the leak detector.
Change-Id: I5b01df6e9ede710a5b624a8a4c21015214140318
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/134288
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
It is possible for an abstract member to be overridden with another
abstract member with different signature (that has, for example, more
optional parameters). In such cases, the noSuchMethod forwarders should
be generated for each distinct signature.
Closes#40248.
Bug: http://dartbug.com/40248
Change-Id: I7974415f0ecb78f05d7265ecf9d57cc0d38e6c41
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132661
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
When loading from dill a library with export errors in it, the errors
would be reported when setting up that scope. There it would be reported
without a location.
Then - if not recompiling it and fixing it - it would be reported again
because of problemsAsJson (with a location).
It would thus be reported twice, one better than the other.
This CL updates the scope building for dill builders to have the option
to supress such errors and then use that option in the incremental
compiler where we use problemsAsJson to reissue problems.
Change-Id: I03430bf8b9996b6e8b7571b8e4e33f3f89f832a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133235
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
By allowing a transformation to tell if it change dthe structure of a
class we can make sure to update the class hierarchy accordingly,
making sure it's up to date for the next computeDelta call in the
incremental compiler.
Change-Id: Iefed3bb1ecbd17b142266ce4a9e1e477f9d2fc87
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133222
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
All handling of the opt-out features were guarded by the experimental flag.
With this CL the opt-out semantics is used irregardless of the
the experimental flag. This supports compiling with opt-out semantics
against libraries which have been compiled with the flag enabled, as will
be the case when the nnbd sdk is unforked.
Closes#40334
Change-Id: I2df5c700f97844bdd3e33bccba7e72013f0c831e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133780
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
- made ProgramCompiler somewhat incremental by letting the user set
the current library and class
- fixed a bug in procedure_builder where extension method wrappers
did not have correct fileEndOffset set, which prevented finding
dart scope at a line when extension methods are used
- added new compileExpressionToJs API to frontend server and
frontend compiler interface
- added ExpressionCompier class that combines IncrementalCompiler
and ProgramCompiler to compile expression at given dart location
to JavaScript
- in JavascriptBundle, set the module name for library tracking in
JavaScript and saved program compilers to a table for incremental
reuse in expression compiler
- Exposed generator from IncrementalCompiler for use in
ExpressionCompiler
- added tests for expression compiler
- added test for compileExpressionToJs API in frontend server tests
Change-Id: Ic5e7829e07030b8ad044da7d35bcf27e9fba81c8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132701
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Gary Roumanis <grouma@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Add a visitor that checks for invalid JS interop usage and reports
diagnostics. Wire the visitor up to the `DevCompilerTarget` and `Dart2jsTarget`.
- Add a message without an analyzer code for this error. In the long term we may
want to also add it to analyzer.
- Add a new package `_js_interop_checks` to share the kernel visitor between
dart2js and ddc. Some of the code is copied from ddc, and in the long term we
can centralize more of the detection of JS interop annotations to this
package.
- Implement the first check to detect definitions of `operator []` or
`operator []=` which are not allowed in JS interop classes.
Change-Id: I095a4b7f4732796dbc3cae55b32d5fc9bcdbd798
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130733
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
When d21c4e4fa5 ([CFE] [Incremental
compiler] Convert all SourceLibraryBuilders to DillLibraryBuilders)
landed it also potentially (and inadvertently) changed the "needed dill
libraries" which tracks which libraries - from a dill file - was
actually needed to do that compilation.
Before, only libraries actually coming from a dill file was in this
list.
After, if asking the class hierarchy for information on the
newly-compiled classes, and then asked for the list of needed dill
libraries to be updated (the normal case in DDC) the libraries that was
just compiled (and converted to dill libarries) was added to the list.
DDC in turn tried to attach all marked libararies to the specific
(actual, "physical") dill file it was loaded from, but as those libraries
wasn't loaded from any dill "physical" dill file, it would crash.
This CL fixes the issue by remembering that these are special.
Change-Id: I037ee8f653165d94b5904e4beacc2423801a3461
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133523
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL adds another "phase" in the incremental compiler: Convert all
SourceLibraryBuilders to DillLibraryBuilders.
This is done to remedy/fix http://dartbug.com/39840 where the FFI
transformation causes us to crash because theres a differense between
the internal world (SourceLibraryBuilder content) and the external world
(the transformed Library). By converting the SourceLibraryBuilder to a
DillLibraryBuilder the internal world (the builder) is now up-to-date
with any changes done in a transformation step.
This CL does not (at least currently) add a callback mechanism for
transformations so they can say if they changed the structure of the
output. This might still be neccessary as we reuse the (kernel) class
hierarchy and that thus is not (with this change) correctly updated.
Change-Id: Ie659d41c47c2b781753a1606db561e0802fd713f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133065
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Also updates StrongComponents to prefer the main component as the root if it is in a cycle. This makes bootstrapping more predictable.
This enables a clean integration of build_runner or ddr (internal) and the frontend_server by allowing it to work with any dev server.
All that is needed is a custom .packages file with `http` uris pointing at a dev server which does all code generation, etc.
Bug: https://github.com/dart-lang/webdev/issues/865
Change-Id: I14533d71e5f7ddac58d98073cf016c2589165e9f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132962
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Johnni Winther