Adds simple method inlining for select patterns only in the dart:_rti
library as an optimization. This helps avoid chains of costly
accesses method calls that in the end simply perform a single
operation and return the result.
For example and snipet from the compiled SDK before:
```
if (_rti._isString(object)) {...}
```
and after:
```
if(typeof object == "string") {...}
```
Issue: https://github.com/dart-lang/sdk/issues/48585
Change-Id: I90596294d35a8fd75d74014c6a12f6e8c726cfcc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324571
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Always throw on `InvalidType` and `AuxiliaryType` in all `DartType`
visitors. These are not expected to exist at this stage in the
compilation.
Change-Id: I8486e4245d6eae895d9420ca64a216aa207af80e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327980
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
Now that the `DartType` class hierarchy is sealed if-else chains over
different `DartType`s can be replaced with exhaustive switch
statements.
Ensures the coverage of all types and provides compile time errors
when new types are added without handling them.
Delete the awkward assertion logic that we had before.
Issue: https://github.com/dart-lang/sdk/issues/53566
Change-Id: Ia400b0dcddb569bb8123a5c1d9e7704f8930bb55
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327982
Reviewed-by: Anna Gringauze <annagrin@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Now that the `DartType` class hierarchy is sealed if-else chains over
different `DartType`s can be replaced with exhaustive switch
statements.
Ensures the coverage of all types and provides compile time errors
when new types are added without handling them instead of the awkward
assertion logic that we had before.
Issue: https://github.com/dart-lang/sdk/issues/53566
Change-Id: Ia78d403610259ca80c30ef52b1c46e475463e277
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327981
Reviewed-by: Anna Gringauze <annagrin@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Now that the `DartType` class hierarchy is sealed if-else chains over
different `DartType`s can be replaced with exhaustive switch
statements.
Ensures the coverage of all types and provides compile time errors
when new types are added without handling them instead of the awkward
assertion logic that we had before.
Issue: https://github.com/dart-lang/sdk/issues/53566
Change-Id: If6228ee05cafbe89e49b137d5b1555dbb3447a56
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327021
Reviewed-by: Anna Gringauze <annagrin@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Now that the `DartType` class hierarchy is sealed if-else chains over
different `DartType`s can be replaced with exhaustive switch
statements.
Ensures the coverage of all types and provides compile time errors
when new types are added without handling them instead of the awkward
assertion logic that we had before.
Issue: https://github.com/dart-lang/sdk/issues/53566
Change-Id: I5624dd53e8cb6f88d10a713e11e1488c28d67698
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327020
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
Now that the `DartType` class hierarchy is sealed if-else chains over
different `DartType`s can be replaced with exhaustive switch
statements.
Ensures the coverage of all types and provides compile time errors
when new types are added without handling them instead of the awkward
assertion logic that we had before.
Issue: https://github.com/dart-lang/sdk/issues/53566
Change-Id: I8b0274d00cfe77fe64c15647b19e75a222afdba8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326902
Reviewed-by: Anna Gringauze <annagrin@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This CL introduces StructuralParameter and StructuralParameterType
classes. They are intended to replace TypeParameter and
TypeParameterType respectively where those were used as type
parameters defined by FunctionTypes. Previously, type parameters of
FunctionTypes were represented by TypeParameter objects with the
‘parent’ field set to null. By introducing StructuralParameter and
StructuralParameterType this CL unambiguously separates the two
notions of type parameters.
TEST=existing
Change-Id: Ida3feb7ad96a7b2acef55840eacba9e36bf2a3e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312264
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This splits visitors for (Tree)Visitor(1) into pure interfaces, mixins,
and a base class with the base implementation. This is a step towards
avoid having an accidental default implementation where a static error
would have been preferable.
This extract a ConstantReferenceVisitor(1) and its corresponding
DefaultMixin from the Visitor(1) interface.
TEST=existing
Change-Id: Ibc55bed9cff76581deaade91a10600c17fafc6dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325704
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This splits visitors for Initializer, Expression, Statement, Member,
and MemberReference into pure interfaces and mixins with the base
implementation. This is a step towards avoid having an accidental
default implementation where a static error would have been preferable.
TEST=existing
Change-Id: I4aa243ce3b3436e05d6164c934df3c44119cd1fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325521
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This splits ConstantVisitor(1) into a pure interface and a
ConstantVisitor(1)DefaultMixin with the base implementation. This is
a step towards avoid having an accidental default implementation where
a static error would have been preferable.
Also removes BodyVisitor1 which was unused.
TEST=existing
Change-Id: I265754e13e0ebcce5c154b16c7ee36854f4ce9fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325400
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
In 8f4e5c8194 the `DiagnosticReporter` was cached in
`DevCompilerTarget` which introduced a memory leak.
Unfortunately our weekly bot that looks for leaks has been out of
commission, but is now coming back online.
This CL fixes the leak by overwriting the field every time, meaing we
don't save a reference to the first one (which is a leak).
Maybe ideally we shouldn't save it as a field at all, but that's a
potential for another day.
Change-Id: Ic740a212c436c475688a1de73c55a2344301e688
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325260
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
There is no need to add a single type parameter to the type table
because it is already represented as a local variable in the scope
where it appears.
Change-Id: I4553d54304a2e3b82e856b8511fdce81cda0653e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324901
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Optimize repetitive calls to isSubtype with a caches to store pairwise
results.
There are currently two caches for sound and unsound results but in the
future that can be combined into a single cache once the library is
aware of error reporting. That single cache could stores "pass", "fail",
or "fails when sound mode but passes in unsound null safety".
Issue: https://github.com/dart-lang/sdk/issues/48585
Change-Id: I49e5794703fd58f1b2bba50e426e25146800fbb8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323707
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This splits DartTypeVisitor(1) into a pure interface and a
DartTypeVisitor(1)DefaultMixin with the base implementation. This is
a step towards avoid having an accidental default implementation where
a static error would have been preferable.
TEST=existing
Change-Id: Ieea9a773a9b70897a2db10cff8d721831a702a8b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324780
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds a typed `TypeParameter.declaration` property to be used
instead of the `parent` property. The `declaration` property holds the
declaration (Class, Method, Extension, etc.) that introduced the
type parameter. `GenericFunction` is the subset of `GenericDeclaration`
that is defined through a `FunctionNode`.
TEST=existing
Change-Id: Ie89e7f5fa12a7966507a250cacc098eb0ce6b30b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323160
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This is a reland of commit ebc96ecb83
Angular codegen emits members that are external so DDC's external
checks need to be more specific to only focus on JS interop. This
also modifies some code logic around whether a member is JS interop
to be less permissive. Before, it claimed that any member is JS
interop if it's external and the enclosing library has a @JS
annotation, but this is only true if there is no surrounding class.
Original change's description:
> [ddc] Don't emit type args on interop invocations
>
> DDC passes type args as the first args for a generic function
> invocation, but interop functions should be excluded from doing
> so, as this leads to passing type args to JS functions.
>
> Change-Id: Ia011beca8c7a0ebb3a7e6c81cd960096045c3a06
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323941
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: Id48337ac4980d9de5de03d895d93cad3ab3a1808
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324542
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This reverts commit ebc96ecb83.
Reason for revert: breaks G3, b/299279625
Original change's description:
> [ddc] Don't emit type args on interop invocations
>
> DDC passes type args as the first args for a generic function
> invocation, but interop functions should be excluded from doing
> so, as this leads to passing type args to JS functions.
>
> Change-Id: Ia011beca8c7a0ebb3a7e6c81cd960096045c3a06
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323941
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: Id1af7f71e80b22b48343c1d918b9431afaf6aaf4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324521
Commit-Queue: Ilya Yanok <yanok@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Thomas <athom@google.com>
DDC passes type args as the first args for a generic function
invocation, but interop functions should be excluded from doing
so, as this leads to passing type args to JS functions.
Change-Id: Ia011beca8c7a0ebb3a7e6c81cd960096045c3a06
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323941
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This is a reland of commit a9fc9ffc4d
Additional changes:
- Set incremental mode on generic class table
- fixes expression evaluation failure discovered by dwds tests
(generic class table was not always defined in compiled expression)
- Allow expression evaluation while the app is running in e2e suite
- Add regression tests for the expression evaluation failure.
Original change's description:
> [ddc] Add module local caches for new types
>
> - Provides fast access for types that are used multiple times in the
> same module.
> - Enable the existing type table cache when running with new types.
> - Add a similar cache for instantiated generic classes. This cache
> is used in the current type system as well to help keep the
> difference between types and classes more clear.
>
> Issue: https://github.com/dart-lang/sdk/issues/48585
> Change-Id: I32103cf0c0bcf9b9771e789c0d04e63a4365a066
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321320
> Commit-Queue: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Mark Zhou <markzipan@google.com>
Change-Id: I9c31d1d07d7f9bb15645ac9aa6e91d35e8906e85
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323501
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
- Provides fast access for types that are used multiple times in the
same module.
- Enable the existing type table cache when running with new types.
- Add a similar cache for instantiated generic classes. This cache
is used in the current type system as well to help keep the
difference between types and classes more clear.
Issue: https://github.com/dart-lang/sdk/issues/48585
Change-Id: I32103cf0c0bcf9b9771e789c0d04e63a4365a066
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321320
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Does several refactorings now that inline class -> extension type:
- InlineExtensionIndex becomes ExtensionIndex
- Comments mentioning inline classes now reference extension types
- Tests are moved to extension types
- Errors now reference extension types instead of inline classes
Change-Id: I26ede8e3aaf6bba5f73847238edeed266fc6a043
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317805
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Incremental compiler only runs procedure transformations during expression compilation, as opposed to modular library transformations
that are run during initial compilation stage on libraries (including JS interop-related transformations).
In this CL:
- Add implementation of `performTransformationsOnProcedure` to dev compiler target
- runs JS interop-related transformations on a procedure.
- Add related expression evaluation tests
- expressions using JS interop and extension types.
Closes: https://github.com/dart-lang/sdk/issues/53048
Change-Id: I085920db9c3af4c680283c574087d8901c99dfcf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319585
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
With this change the Dart Core Object members (`.hashCode`,
`.runtimeType`, `.noSuchMethod()`, `.toString()`, and
`operator ==`) are no longer installed onto the native JavaScript
Object prototype. This is done because the Object prototype will be
sealed as a security precaution in some environments to avoid
prototype pollution exploits.
This means that dispatching to these APIs will change when the
compiler cannot know if the receiver may be null or a value from
JavaScript interop. In those cases a call to a helper method is
inserted instead. The helpers will probe for the API on the value,
call it if available or execute a default version.
NOTE: Many other native JavaScript prototypes are still modified. This
change is only for the Object prototype.
Issue: https://github.com/dart-lang/sdk/issues/49670
Change-Id: Iddb3a48e790dd414aa3254d729535c4408e99b3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310971
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Several changes are made:
- createDartExport now does not export methods that define type parameters.
- createStaticInteropMock adds conformance checks to make sure implementing
members can handle all possible values of a type parameter in an interop
member. An error is added to reduce confusion around this.
- Export creator now uses dart:js_interop_unsafe for a lot of its lowering
as the dart:js_util equivalents are buggy when it comes to calling exported
functions in JS with JS types.
- Small code changes are added to backends to handle the above changes.
Change-Id: Ie3b6b157930537267f270b60373b2b17e0a14344
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316141
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This renames InlineClass to ExtensionTypeDeclaration, and InlineType
to ExtensionType. Members of extension type declarations are called
extension type members instead of extension type declaration members
for "brevity".
TEST=existing
Change-Id: I91ed62533ddd345644492f04dc3310d007460288
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316780
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This removes ExtensionType, ExtensionTypeShowHideClause and
CallSiteAccessKind from package:kernel which where only used by the now
removed 'extension-types' experiment.
A follow-up CL will rename InlineClass/InlineType to
ExtensionTypeDeclaration/ExtensionType to match the names of the
Extension Type feature currently being implemented.
TEST=existing
Change-Id: I58d2e8b0a92ac61329ee161cc6884a2c0e6f87ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316420
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
A side effect of DDC's new shared runtime ('dart:_rti') is that previously @notNull-annotated code paths were being extraneously null-checked. This is partly responsible for the slowdowns in some internal mixed-mode apps found in testing.
Change-Id: I3f619cfd23688f3eb4ada0079ad1664d39a7e010
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/315640
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
When mixin applications introduce forwarding stubs with covariant
checks they can contain uses of type parameters that belong to the
synthetic mixin application class. The type environment needs to
be updated to contain those type parameters.
Also cleanup some comments, variable names, and the code to avoid
an assertion failure. Methods can contain covariant checks on the
arguments, not just setters.
Issue: https://github.com/dart-lang/sdk/issues/52688
Change-Id: Ifd91f76de85cb2092b0a3a0c4a808f2660eb5c17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/308460
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Determines the ultimate representation type of an inline class to
determine if it can use external members. This allows users to
elide @JS if they don't need renaming. This CL adds some static
errors around inline interop members so its clearer that the
inline class should have an interop representation type.
There's a bit of cleanup in this CL too around interop members,
where extension members on @Native classes are now correctly
considered as interop members by the error checker.
Change-Id: I4d870d204933ea11b347ab5bb2e3de1b962f5ea3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/308249
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Nicholas Shahan