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>
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>
Redirectig factories are encoded in a special way to "recover" their data
(together with _redirecting# field). Before this CL, if a redirecting
factory was async (that's an error) it was encoded so we couldn't load
that dill again and that we would throw an error if we tried.
This CL fixes that.
Change-Id: If73ef5f662fb23bc083eb1af086d9d7694ca538c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133061
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Use the VM service to find leaks in the incremental compiler via the
incremental compiler test suite.
Currently the following tests leak:
incremental_load_from_dill/no_outline_change_2
incremental_load_from_dill/no_outline_change_6
incremental_load_from_dill/no_outline_change_7
incremental_load_from_dill/no_outline_change_10
incremental_load_from_dill/no_outline_change_34
Change-Id: Ie05ad5994f518422c553dc52bd57908ebbf1b16b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132283
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This expands the "hack" that was added to automatically opt out tests.
It was not working for the multi-tests in the opt out directories since
the sources were being generated into the generated/tests/ directory.
Change-Id: If403ff36c2250f1dbdd04dd5c6ee81bf63c9ab22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132811
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Johnni Winther