When the canary and ddc modules flags are passed together use the
expression compiler worker uses the LibraryBundleCompiler to compile
the expression to be evaluated. This ensures the compiler JavaScript
matches the expected format and representation of the compiled library.
Change-Id: I4667522a6640707265a3f38770a17fd696c840f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/479400
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This reverts commit c616db31d2.
Reason for revert: Fix landed downstream in Flutter engine: https://github.com/flutter/flutter/pull/180127
Original change's description:
> Revert "[ DDC / CFE ] Add support for allowing imports of unsupported libraries"
>
> This reverts commit b5e60be49d.
>
> Reason for revert: broke Flutter web engine tests
>
> Original change's description:
> > [ DDC / CFE ] Add support for allowing imports of unsupported libraries
> >
> > This change adds support for allowing for imports of unsupported
> > platform-specific libraries when the
> > `--include-unsupported-platform-library-stubs` flag is provided to the
> > CFE.
> >
> > This flag sets the `includeUnsupportedPlatformLibraryStubs` property in
> > `TargetFlags`, which `Target`s can use to conditionally return different
> > `DartLibrarySupport` objects with different supported/unsupported
> > library sets.
> >
> > A `checkForUnsupportedDartColonImports` function has been added to
> > `Target` that uses the value of `dartLibrarySupport` to determine if
> > there's any unsupported library imports. This function is called after
> > the various transformation operations provided by the `Target`
> > implementation, meaning the import of an unsupported library specified
> > in `dartLibrarySupport` will now result in a compilation error (this
> > includes `dart:mirrors` imports for VM targets when mirrors are
> > disabled, which was previously handled by the VM itself).
> >
> > Related to https://github.com/dart-lang/sdk/issues/62125
> >
> > TEST=Tests added / modified
> >
> > Change-Id: Ife819b2e1a6d28f67d80aab6701cd23a1724aa4d
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465760
> > Reviewed-by: Nicholas Shahan <nshahan@google.com>
> > Reviewed-by: Johnni Winther <johnniwinther@google.com>
> > Commit-Queue: Ben Konyi <bkonyi@google.com>
>
> Change-Id: I0b59f00e55a2424f783351abd977eb38409ce01f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469100
> Reviewed-by: Nate Biggs <natebiggs@google.com>
> Commit-Queue: Alexander Markov <alexmarkov@google.com>
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
Change-Id: I1ae2eac675432286aebabea3c1f58caf35a27fbb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469240
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
This reverts commit b5e60be49d.
Reason for revert: broke Flutter web engine tests
Original change's description:
> [ DDC / CFE ] Add support for allowing imports of unsupported libraries
>
> This change adds support for allowing for imports of unsupported
> platform-specific libraries when the
> `--include-unsupported-platform-library-stubs` flag is provided to the
> CFE.
>
> This flag sets the `includeUnsupportedPlatformLibraryStubs` property in
> `TargetFlags`, which `Target`s can use to conditionally return different
> `DartLibrarySupport` objects with different supported/unsupported
> library sets.
>
> A `checkForUnsupportedDartColonImports` function has been added to
> `Target` that uses the value of `dartLibrarySupport` to determine if
> there's any unsupported library imports. This function is called after
> the various transformation operations provided by the `Target`
> implementation, meaning the import of an unsupported library specified
> in `dartLibrarySupport` will now result in a compilation error (this
> includes `dart:mirrors` imports for VM targets when mirrors are
> disabled, which was previously handled by the VM itself).
>
> Related to https://github.com/dart-lang/sdk/issues/62125
>
> TEST=Tests added / modified
>
> Change-Id: Ife819b2e1a6d28f67d80aab6701cd23a1724aa4d
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465760
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Commit-Queue: Ben Konyi <bkonyi@google.com>
Change-Id: I0b59f00e55a2424f783351abd977eb38409ce01f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469100
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This change adds support for allowing for imports of unsupported
platform-specific libraries when the
`--include-unsupported-platform-library-stubs` flag is provided to the
CFE.
This flag sets the `includeUnsupportedPlatformLibraryStubs` property in
`TargetFlags`, which `Target`s can use to conditionally return different
`DartLibrarySupport` objects with different supported/unsupported
library sets.
A `checkForUnsupportedDartColonImports` function has been added to
`Target` that uses the value of `dartLibrarySupport` to determine if
there's any unsupported library imports. This function is called after
the various transformation operations provided by the `Target`
implementation, meaning the import of an unsupported library specified
in `dartLibrarySupport` will now result in a compilation error (this
includes `dart:mirrors` imports for VM targets when mirrors are
disabled, which was previously handled by the VM itself).
Related to https://github.com/dart-lang/sdk/issues/62125
TEST=Tests added / modified
Change-Id: Ife819b2e1a6d28f67d80aab6701cd23a1724aa4d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465760
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Turns out we'll sometimes be given the script uri as a package uri,
so we have to support that.
To further complicate things we're not necessarily given a package
config to translate from so we need to use the kernel component as a
backup.
Change-Id: I06ceb136b0b03164aaf7412d5332ae9c4c3338c4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447220
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
For expression evaluation we want to be "more than dart" in that if for
instance we can see (in the debugger) that a List contains `B`s (even
if it's typed as containing `A`s) we'd like to be able to access things
on `B` (without manually having to cast to either `B` or `dynamic`).
Furthermore - when we in the debugger can see that it's a `B`, and that
`B` has, say, a field `_privateField` or a method `_privateMethod` we'd
like to be able to access that even if `B` is in another library.
This CL - for expression evaluation - makes dynamic accesses and calls
where we would normally issue a "missing getter" (etc) error, and tries
to create a `Name` so private access is possible.
Change-Id: I887318a50413e9a5f11ec685b27719edd312dca0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/446260
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Update the last known good component after a recompile reject back to
the expected state before the recompile.
Adds tests for expression compilation after recompile accept and
recompile reject cases with `--target=dartdevc`. Similar to existing
tests for the VM.
Removes calls to `_generator.accept()` and
`component.computeCanonicalNames()` from `compileExpressionToJs()`.
These were added very early in the prototype implementation and it is no
longer clear why they would be needed.
Added some additional test cases for expression compilation involving
import resolution because the change that originally added the
`component.computeCanonicalNames()` call implies it was needed for that
reason. See: https://dart-review.googlesource.com/c/sdk/+/138010
TEST=pkg/frontend_server/test/frontend_server_test.dart,pkg/dev_compiler/test/expression_compiler/expression_compiler_test.dart
Change-Id: I9c04bd46e56b33dc654d00fb330de29c3c643a5b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434522
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
When wildcard method arguments should be removed from the scope before
attempting to evaluate an expression. Otherwise their names are invalid
and cause a Dart compile time error.
Add tests for all forms of wildcards in expression evaluation.
Change-Id: I21a7676a1495383926552a1039789f7d29256a67
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431951
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This new update adds fixes + tests for cross-module super mixins. Super getters can refer to mixins compiled in other modules, so we need to expose all mixin names to make them accessible from their enclosing library.
This is a reland of commit e4c4d0f839
Original change's description:
> [ddc] Overhauling tearoff equality and identity.
>
> Hot reload requires DDC to update how its tearoffs are represented. Tearoffs obey the following conventions:
> * Instance tearoffs are never identical
> * Tearoffs with the same object target and name have the same hash code (even if they resolve to different functions across hot reloads)
> * Two separate tearoffs of the same member are equal
>
> To support this, tearoff equality must not depend on the bound object and method but a composite of the bound object, torn off member name, and the exact class/object from which the member was torn off.
>
> Notable changes:
> * Methods' immediately bound targets are emitted with member signatures. This is required to determine the bound targets for instance and dynamic tearoffs. Bound targets are identified by `libraryUri:class` strings.
> * `applyMixin` passes in a 'true' bound target. This is because mixin applications' members are considered children of their 'on' class (not the mixed in class) wrt equality/hashCode.
> * `bind` is modified to pass in its 'true' bound object to support mixins' super getters.
> * `tearoff` and `staticTearoff` are modified to accept a bound target string (only required for static tearoffs, as they are bound at tearoff-creation-time).
> * Static tearoffs avoid using their bound object for hashcode and equality, as these libraries may be wrapped in proxy objects.
> * Tearoff equality and hashCode are updated to consider bound object, bound name, and its bound method's immediate target.
> * 'noSuchMethod' and 'toString' methods are always accessed through their extension property during signature lookups.
>
>
> Change-Id: Ica5501b6860c605db50aa945bafb6802a7317511
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/406723
> Reviewed-by: Nate Biggs <natebiggs@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Commit-Queue: Mark Zhou <markzipan@google.com>
Change-Id: I645992030f9106c158426412387ddecafc78e3f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415102
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
* Remove accessing nullability through a library node since they no
longer differ depending on the language version.
* Cleanup old comments related to legacy types.
* Cleanup dead code in nullable inference of `.toString()` calls.
Change-Id: I099180e7bab4f0f1ea7cf23a6c0fc015ab0413b3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415160
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
This reverts commit e4c4d0f839.
Reason for revert: Breaks are blocking roll into flutter
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8720592021329723649/+/u/run_test.dart_for_web_canvaskit_tests_shard_and_subshard_0/stdout
Original change's description:
> [ddc] Overhauling tearoff equality and identity.
>
> Hot reload requires DDC to update how its tearoffs are represented. Tearoffs obey the following conventions:
> * Instance tearoffs are never identical
> * Tearoffs with the same object target and name have the same hash code (even if they resolve to different functions across hot reloads)
> * Two separate tearoffs of the same member are equal
>
> To support this, tearoff equality must not depend on the bound object and method but a composite of the bound object, torn off member name, and the exact class/object from which the member was torn off.
>
> Notable changes:
> * Methods' immediately bound targets are emitted with member signatures. This is required to determine the bound targets for instance and dynamic tearoffs. Bound targets are identified by `libraryUri:class` strings.
> * `applyMixin` passes in a 'true' bound target. This is because mixin applications' members are considered children of their 'on' class (not the mixed in class) wrt equality/hashCode.
> * `bind` is modified to pass in its 'true' bound object to support mixins' super getters.
> * `tearoff` and `staticTearoff` are modified to accept a bound target string (only required for static tearoffs, as they are bound at tearoff-creation-time).
> * Static tearoffs avoid using their bound object for hashcode and equality, as these libraries may be wrapped in proxy objects.
> * Tearoff equality and hashCode are updated to consider bound object, bound name, and its bound method's immediate target.
> * 'noSuchMethod' and 'toString' methods are always accessed through their extension property during signature lookups.
>
>
> Change-Id: Ica5501b6860c605db50aa945bafb6802a7317511
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/406723
> Reviewed-by: Nate Biggs <natebiggs@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Commit-Queue: Mark Zhou <markzipan@google.com>
Change-Id: Ic5694976260189f7215dfa3c2318e9a0656f0de6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415100
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Hot reload requires DDC to update how its tearoffs are represented. Tearoffs obey the following conventions:
* Instance tearoffs are never identical
* Tearoffs with the same object target and name have the same hash code (even if they resolve to different functions across hot reloads)
* Two separate tearoffs of the same member are equal
To support this, tearoff equality must not depend on the bound object and method but a composite of the bound object, torn off member name, and the exact class/object from which the member was torn off.
Notable changes:
* Methods' immediately bound targets are emitted with member signatures. This is required to determine the bound targets for instance and dynamic tearoffs. Bound targets are identified by `libraryUri:class` strings.
* `applyMixin` passes in a 'true' bound target. This is because mixin applications' members are considered children of their 'on' class (not the mixed in class) wrt equality/hashCode.
* `bind` is modified to pass in its 'true' bound object to support mixins' super getters.
* `tearoff` and `staticTearoff` are modified to accept a bound target string (only required for static tearoffs, as they are bound at tearoff-creation-time).
* Static tearoffs avoid using their bound object for hashcode and equality, as these libraries may be wrapped in proxy objects.
* Tearoff equality and hashCode are updated to consider bound object, bound name, and its bound method's immediate target.
* 'noSuchMethod' and 'toString' methods are always accessed through their extension property during signature lookups.
Change-Id: Ica5501b6860c605db50aa945bafb6802a7317511
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/406723
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Closes https://github.com/dart-lang/sdk/issues/60109
Both getClassMetadata and getClassesInLibrary can be called before
main is called. In order to support this, libraries should be
initialized so that these debugger APIs can inspect them. Similarly,
SDK libraries that are needed before any code can run should be
initialized. In order to support this, they are initialized on the
first initializeAndLinkLibrary call and reinitialized during a
hotRestart (since the libraries are recreated).
Tests are added to evaluate these methods before main is called.
The debugger test helpers are amended to:
- Support breakpoints within the bootstrap script. This is done by
caching the script and querying to see if it has the breakpoint if
the input sources do not.
- Refactor shared test expectation logic.
- Remove an unused method.
Change-Id: I5534d7008436a51243cf51dba01bb8ad06adca69
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410602
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
The attached bug shows an issue users have been encountering where a constructor seems to be undefined. It turns out this is because DDC is trying to read the constructor from the wrong library.
This is happening because both 'package:dio' and a sister package 'package:dio_web_adapter' both contain a library with the same path: 'src/adapter.dart'. 'BrowserHttpClientAdapter' the class they are trying to reference is defined in 'package:dio/src/adapter.dart'. However, due to a naming collision, their import is referencing 'package:dio_web_adapter/src/adapter.dart'.
This naming collision happens because of the logic in '_jsLibraryAlias'. By truncating the start of the import URI (i.e. 'dio/' and 'dio_web_adapter/') the two libraries map to the same alias. This alias is then used to as the key in the AMD module export object and since both libraries are in the same module, only the second one gets exported.
This code may have been written with the assumption that libraries from different packages would always be in different modules (in which case the shortened paths shouldn't collide) but this is not the case. The fix is to use the full import URI including the package name.
In writing the attached modular test I discovered another issue that only affects es6 imports. The ScopedId resolver was not considering NameSpecifier as a declaration point for variables. This lead to a similar name collision since the import alias's name was also being derived from a truncated import URI. In the test, both 'f1/foo.dart' and 'f2/foo.dart' were being imported 'as foo'. Now one is 'as foo' and the other is 'as foo$'.
The first issue affects both AMD and es6 while the second issue only affects es6. The modular tests run with es6 so the new test fails if either of these fixes is not in place.
The new DDC module system is not affected by either issue since it doesn't use NameSpecifiers and it uses the full import URI as a string to register libraries rather than a shortened alias.
Tested on TGP and with a local Flutter application.
Bug: https://github.com/dart-lang/sdk/issues/56498
Change-Id: I5bdb945cfbe615874b40e2fc4ebba31b661cf3b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410260
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Tearoffs are now represented as a closure that resolves an underlying bound context and property on access. `_boundMethod` and RTI getters must also be evaluated late.
Additionally, we now both canonicalize static methods and tag them with their types at class-declaration time (though lazily) - so that late resolved closures have access to their types.
Some tests have been updated to expect simpler errors. DDC traditionally emits slightly different errors that might aid in debugging.
Change-Id: I1f762b8df45e0766d16dbc8688073768c8bfd233
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/401321
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Some CFE lowerings (e.g. pattern lowerings) result in nested scopes containing VariableDeclarations with the same 'name'. The current DDC transform translates these to the exact same name in JS leading to incorrect semantics.
The `TemporaryId` mechanism automatically renames any variables with the same name that would shadow each other. So we re-use that here to ensure the variables all have a unique name if the CFE hasn't already given them one. If the name is already okay (i.e. not shadowing something else), the name in JS will appear unchanged.
Side note: In a future change perhaps we should rename `TemporaryId`. The general mechanism it implements is more useful than its original intended use.
Fixes: #59613
Change-Id: I708c72528d5df19af48dde01163d375a5588baae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/398504
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
These are no longer handled with the new module format,
so skip them when that's enabled. This is the last piece
to get expression evaluation tests working again with the
new format.
Change-Id: I92933363ea4e275f7a3f1c9cd62e24b0f7987f49
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/393162
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
- Exposes a minimum set of APIs that are needed by DWDS
a single class Debugger.
- Renames some APIs and modifies the signature to better
align with what's happening and what DWDS actually uses.
Similarly, modifies the internal APIs to handle the new format.
- Modifies expression evaluation test suite to handle the
new module format correctly.
- Modifies LibraryBundleCompiler to emit the right export name.
- Adds/adapts existing tests for the runtime debugger APIs.
With this, all tests within pkg/dev_compiler/test/expression_compiler
pass with the new module format with the exception of two tests within
expression_compiler_e2e_ddc_null_safe_test, which will be fixed
in a future CL.
Change-Id: I296496441ea421ecb57bed3b2e90b92365fef510
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/391308
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Converts kernel_worker.dart.snapshot and dartdevc.dart.snapshot to
AOT snapshots. Fixes tests and paths in the code accordingly.
TESTS=ci
Change-Id: Ib99b2a3343e23252c3a6b5295b0d20f0f486aede
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381388
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
The old runtime type system required prototype manipulations to
correctly capture a type that contained an embedded type argument.
This was achieved by assigning the prototype of the array in the
JSArray factories and connecting the prototype chain so JSArray
"extended" the native JavaScript Array.
In the new runtime type system these special case operations are
not needed.
Remove the error state for `JS_CLASS_REF()` for interface types
with type arguments. The class definitions are now defined outside
of closures so they can be referenced just like classes without
type arguments.
Update debugger API to manually identify the library for JSArray and
remove unnecessary accesses of `.length` via JavaScript.
Cleanup skipped test cases for the old runtime type system.
Change-Id: I57ab0c968ec06437dad0e081f6334268e99dbc69
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385102
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This is a reland of commit e7658520bb
Fixes in the reland + context:
Type parameters emitted in implicit type checks on covariant mixin forwarding stubs may reference type arguments in anonymous classes. We reduce this to their mixin's implementing subclass to avoid generating RTI rules for anonymous classes.
Previous implementations would 'translate' type parameters to that of their mixed in type, but that strategy fails if the implementing subtype shuffles the order of type arguments relative to its mixed in type (demonstrated in the test - though not actually relevant in the Flutter break).
Original change's description:
> [ddc] Overhauling DDC's generic class representation.
>
> Prior to this change, DDC represented generic classes as closures over type parameters (with type arguments provided at runtime), which tightly coupled generic class definitions with their types and concrete instantiation.
>
> This rewrite decouples this representation, letting us 1) bind type information late and 2) separate generic class definitions from their instantiation.
>
> Notable changes:
> - Generic classes are now declared at top level (rather than within in closures).
> - RTIs are now passed to generic class constructors at runtime (except for JS Interop classes). Only the instantiated class's RTI is required (and it's retained up the type hierarchy).
> - Type signature resolvers are now lambdas that accept a type environment RTI at runtime. While signatures are still attached early, their instances' RTIs are now needed at runtime.
> - Generic classes, constructors, and factories are now evaluated in a 'Class' type environment.
> - An `RtiTypeEnvironment` is introduced to represent lookups on an RTI type environment bound to a parameter. These are used when evaluating type signatures and at constructor/factory bodies.
> - Type recipes now emit Class type parameters with names - but continue to emit method type parameters with de Bruijn indices. This is because indices aren't stable across subtypes.
> - Certain debugger functions now require instances (e.g.,`getClassMetadata`).
> - Adds a special flag for non-external JS interop factory constructors to emit 'true' types (versus 'any').
>
> Change-Id: I7cbeaaf666dd4f9bd5e3ef22a1163a659fc0ee48
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365863
> Reviewed-by: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Kallen Tu <kallentu@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Nate Biggs <natebiggs@google.com>
> Commit-Queue: Mark Zhou <markzipan@google.com>
Change-Id: I9b6f69b7150631f28442675c4230e093e3b821d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379511
Reviewed-by: Kallen Tu <kallentu@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This reverts commit e7658520bb.
Reason for revert: Causing failures in both Dart->Flutter roller and web_dev package.
Original change's description:
> [ddc] Overhauling DDC's generic class representation.
>
> Prior to this change, DDC represented generic classes as closures over type parameters (with type arguments provided at runtime), which tightly coupled generic class definitions with their types and concrete instantiation.
>
> This rewrite decouples this representation, letting us 1) bind type information late and 2) separate generic class definitions from their instantiation.
>
> Notable changes:
> - Generic classes are now declared at top level (rather than within in closures).
> - RTIs are now passed to generic class constructors at runtime (except for JS Interop classes). Only the instantiated class's RTI is required (and it's retained up the type hierarchy).
> - Type signature resolvers are now lambdas that accept a type environment RTI at runtime. While signatures are still attached early, their instances' RTIs are now needed at runtime.
> - Generic classes, constructors, and factories are now evaluated in a 'Class' type environment.
> - An `RtiTypeEnvironment` is introduced to represent lookups on an RTI type environment bound to a parameter. These are used when evaluating type signatures and at constructor/factory bodies.
> - Type recipes now emit Class type parameters with names - but continue to emit method type parameters with de Bruijn indices. This is because indices aren't stable across subtypes.
> - Certain debugger functions now require instances (e.g.,`getClassMetadata`).
> - Adds a special flag for non-external JS interop factory constructors to emit 'true' types (versus 'any').
>
> Change-Id: I7cbeaaf666dd4f9bd5e3ef22a1163a659fc0ee48
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365863
> Reviewed-by: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Kallen Tu <kallentu@google.com>
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Nate Biggs <natebiggs@google.com>
> Commit-Queue: Mark Zhou <markzipan@google.com>
Change-Id: I8ea12847bb2a4d096db0799c85f3175f1c5df3be
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379420
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Auto-Submit: Nate Biggs <natebiggs@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
DDC hot reload requires a new module format, which is
currently represented by the intersection of the DDC
module format and canary. Some of the expression compiler
tests only test the AMD module format (all of them run both
canary and non-canary since those are two different try
bots). Add code to test the DDC module format as well.
Change-Id: Ie3ca0dd3d63985d3222ab09730a82935481076a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/377764
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Prior to this change, DDC represented generic classes as closures over type parameters (with type arguments provided at runtime), which tightly coupled generic class definitions with their types and concrete instantiation.
This rewrite decouples this representation, letting us 1) bind type information late and 2) separate generic class definitions from their instantiation.
Notable changes:
- Generic classes are now declared at top level (rather than within in closures).
- RTIs are now passed to generic class constructors at runtime (except for JS Interop classes). Only the instantiated class's RTI is required (and it's retained up the type hierarchy).
- Type signature resolvers are now lambdas that accept a type environment RTI at runtime. While signatures are still attached early, their instances' RTIs are now needed at runtime.
- Generic classes, constructors, and factories are now evaluated in a 'Class' type environment.
- An `RtiTypeEnvironment` is introduced to represent lookups on an RTI type environment bound to a parameter. These are used when evaluating type signatures and at constructor/factory bodies.
- Type recipes now emit Class type parameters with names - but continue to emit method type parameters with de Bruijn indices. This is because indices aren't stable across subtypes.
- Certain debugger functions now require instances (e.g.,`getClassMetadata`).
- Adds a special flag for non-external JS interop factory constructors to emit 'true' types (versus 'any').
Change-Id: I7cbeaaf666dd4f9bd5e3ef22a1163a659fc0ee48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365863
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
This includes a major version change from 127 to 128.
This change reverts some of the workarounds wrt
errors now that Chrome has fixed the original issue.
Change-Id: I639ee62964bf2d70e425071a1d541171f3b4af64
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/378240
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This allows internal Set classes to be referenced by our runtime.
Context: incoming changes to our generic types (required for hot reload) requires that RTIs be passed to generic classes on instantiation. Moving our Set implementation into our private runtime and making their classes public allows us to directly reference them without clobbering names externally.
Change-Id: Ie47b3263ebbf2650d314b5285a2d50f3abd1a664
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373327
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Late local variables are lowered by the CFE into a local:
* backing store variable
* get method
* set method
* isSet local variable (optionally when the type is nullable)
This change updates the name in JavaScript used for the backing store
variable to match the name for the late variable from the original
source. It also updates the scope information passed for expression
evaluation to remove the lowered name and replace it with the original
so evaluations will work as well.
The name change avoids the hiding performed by the debugger on
recognized temporary names so it appears in the list of local variables.
b/343405209
Issue: See https://github.com/dart-lang/sdk/issues/55918
Change-Id: I6b65a62baf6f26f6e9cfee9f14667d021e16645e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369506
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Today, support for expression evaluation in DDC uses a lot of
information. To properly support compiling expressions in arbitrary
frames, we consume source-maps, module metadata, and full kernel
components at various stages of the process. This data is already
plumbed and available for non-sdk modules in our debugging systems
(frontend-server, webdev, g3), however it is not available the Dart
SDK module itself. Because of that, the expression compiler today
rejects all expression evaluation requests when the target is a Dart
SDK library.
Until the fix the availability of this data everywhere, we believe
we can support a limited form of expression evaluation: only
evaluation of libary level expressions. Basically, expressions
where scope data is not necessary and kernel outlines are sufficient to
compile the expression.
Here we introduce logic to recognize the first offset location of a
library, which is a clear indicator that no scope data is needed and
a library level expression evaluation is being requested.
This change is an attempt to help resolve
https://github.com/flutter/devtools/issues/7766. Note: just like
changes were needed here in the worker and test-compiler files, it
is possible that some change may be necessary in dwds and other
parts of the pipeline. Additional validation will be needed after
this lands.
Change-Id: Iff081a24ecb05092407279a0a7ed3d38c13cf41d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367981
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Nicholas Shahan