When we lower an uninitialized static field to a cell, we gives the cell
a mangled name and create a getter/setter pair with the original field
name. The getter/setter simply call the appropriate members on the cell.
This means that other libraries, even ones that haven't been transformed
(e.g. during modular compilation) will still interoperate correctly,
since the transformed library still has the same external signature.
Change-Id: I88edcb71fa5cb910869b4266628a029ad358b77e
Fixes: https://github.com/dart-lang/sdk/issues/45854
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214064
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
It's clear from the comments that the first case was meant to test the
variable `v` (which has type `Object?`), and the second was meant to
test the variable `d` (which has type `dynamic`), but they
accidentally were both referring to `v`.
Change-Id: I1c36350689d20fa8d86c7d1c66918307f5fe2253
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214132
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
We use an extension getter instead of an instance getter because
it doesn't conflict with any potential existing or future enums
which want an element named `name`.
Keeping the namespace for enum elements open is a priority.
We currently only reserve `index` and `values`.
BUG: https://github.com/dart-lang/language/issues/1511
Fixes language issue #1511, which is a long-standing request,
and should replace a number of alternative implementations
which are based on parsing the `toString()`.
This version has two fields on the shared superclass, the index
and private name, and has a separate `toString` for each `enum` class
which hard-codes that enum's class name.
An earlier version had both `"name"` and `"ClassName.name"` as fields
to be able to reuse the same `toString` method on all enum classes,
but that cost too much for JS compiled code.
Even having just `ClassName.` as a field and then combining inside
`toString` requires more code to create the enum instances.
Instead this version hardcodes the `ClassName.` string once
in the `toString` method, which means each enum class has its own
toString (which can *potentially* be tree-shaken then.)
This still tree-shakes slightly worse than the previous implementation
where every enum class had its own `index` and `_name` fields
independent of each other, which could then be tree-shaken independently.
However, the `index` was already made an interface member with the
addition of the `Enum` interface, so code which accesses `.index`
on something of the `Enum` supertype could prevent tree-shaking of
all enum classes' `index` fields.
Likewise any general access to the "name" of an enum would necessarily
do the same for the name.
This CL makes up for some of that by sharing more implementation
between enum classes.
DartVM AOT CodeSize impact: ~0.15% regression on gallery (little less on big g3 app)
TEST= New tests added to enum_test.dart
Change-Id: Id25334e6c987f470f558de3c141d0e3ff542b020
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210480
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Previously, the FfiCode constructor allowed the error type to be
overridden, but no use of that constructor actually took advantage of
it.
Hardcoding the type of all FFI error codes makes the implementation of
error codes more uniform, which helps pave the way for code
generation.
If in the future, we decide that we actually need some FFI error codes
to have different error types than others, we can always add the
functionality back in.
Change-Id: I5061281089aeba0185fd8ebaa08a82482e91f2ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214070
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
* Fix regression (https://dart-review.googlesource.com/c/sdk/+/214040).
* Add tests for invalid configurations with and without named configs.
* Add a custom test matrix for testing.
Change-Id: If169571c3163c5f4da1d3d989a2fcff6dc0a7d97
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214044
Commit-Queue: Alexander Thomas <athom@google.com>
Commit-Queue: William Hesse <whesse@google.com>
Auto-Submit: Alexander Thomas <athom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Failure to check for losing the race can result in the same object being added to the remembered set twice, and processing the remembered set is not idempotent.
Previously there could be no such race, but the combination of lazy initialized const maps/sets and isolate groups means that now more than one Dart thread can be writing to the same object.
TEST=cfe and fuzzer bots, flaky
Bug: https://github.com/dart-lang/sdk/issues/47233
Change-Id: I7684ea6ba90941bb174c35ae040372aa331ac4c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214077
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
CFE transformation to add a function body for external fields,
getters, and setters, routing to the relevant js_util
getProperty and setProperty optimized calls.
Change-Id: Ia3d0f05fda50f20d217c0a67e0fd636bb774000b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213600
Commit-Queue: Riley Porter <rileyporter@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Change-Id: I04368d00010e81148c608ba0d8f0371a516862e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213966
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Copies the same skipped tests from the dart2js status file.
Change-Id: I617f182a9fd64e1293b05bdbcbc61bfb2115bf99
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213968
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Add fix definitions and tests for renamed class and top level constants in
`dart:developer` and `dart:io`.
Change-Id: I6851bd61c68fdcff461117fe8f2ab1c3890cb9df
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214000
Auto-Submit: Nate Bosch <nbosch@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Instead getDisplayString() should be used.
Change-Id: I1c988bc9d193398aadbb32620e01f11ea3e353d4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213900
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
* Fail test.py if an invalid named configuration is used.
Cq-Include-Trybots: luci.dart.try:vm-ffi-android-product-arm64c-try
Change-Id: Ib700511a639ee39fd58441dd6fee8bd6dad8c2e5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214040
Reviewed-by: William Hesse <whesse@google.com>
When testing the subtype relation between two generic function types,
uninstantiated type variables can appear as an argument or return type
of one function while a concrete type appears in corresponding
position of the other function. A subtype relation can be established
if the bound of the type variable is a subtype of the concrete type.
For example given a type variable T with bound B and a concrete type
C we can say:
T <: C when T <: B <: C holds.
T <: B is true by the definition of interface subtypes `T extends B`.
This change adds a test for B <: C.
Add a new class used only when it appears we may need to test these
subtype relations. The class is used to plumb the bound information
of type variables further into the subtype check algorithm where it
is now tested.
Add a top level variable to index the total number of type arguments
seen during a subtype check through nested function types.
Change-Id: If6aa13e7b758f7fedcb5dbd8e09d366082198e61
Fixes: https://github.com/dart-lang/sdk/issues/38816
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213527
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Move the method body out of one giant JS foreign function and into
Dart code with small JS foreign function calls inside.
* Removes the confusion around what it actually means when we use
Dart String interpolation within the JS function template.
* Highlights the operations that actually need the JS foreign
function.
* Allows for syntax highlighting and automatic formatting of this
code.
* Allows for IDE "jump to definition" for class members that were
previously inside the template.
These changes were developed by diffing the compiled output to
ensure the changes were as minimal and inconsequential as possible.
Intentional diffs include:
* Add a required message argument to `dart.assertFailed()`.
* Add local variables for `varianceType`, `typeArg1`, and
`typeArg2`.
The only other diff was the loop variable incrementing:
`++i` -> `i = i + 1`
Change-Id: I76a1522fa4950f05748f905e1aec32c8b7dd4670
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213526
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Move the method body out of one giant JS foreign function and into
Dart code with small JS foreign function calls inside.
* Removes the confusion around what it actually means when we use
Dart String interpolation within the JS function template.
* Highlights the operations that actually need the JS foreign
function.
* Allows for syntax highlighting and automatic formatting of this
code.
* Allows for IDE "jump to definition" for class members that were
previously inside the template.
These changes were developed by diffing the compiled output to
ensure the changes were as minimal and inconsequential as possible.
The only diffs that appeared beyond the intentional addition of
the `t1Bound` and `t2Bound` local variables were:
* Using the top level variable for a type:
`dart.nullable(core.Object)` -> `T$.ObjectN()`
* Loop variable incrementing:
`i++` -> `i = i + 1`
Change-Id: I55fa3fa94b984c67b18a744837843d458231c4d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213525
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Fixes https://github.com/dart-lang/sdk/issues/47211
Much of this change is about decision-making based on the _type_ of the
function in a FunctionReference, or the receiver of that function, in the
case of prefixed identifiers or property access.
Previously, there was a rule that only direct references to functions
(top-level, local, and method) could be torn off and type-instantiated.
That rule has been reversed (#1812), so a lot of unraveling has to be
done here.
`e.call<...>` is now legal for _any_ generic function-typed expression
`e`, which certainly may be an expression without a staticElement.
Additionally, `e<...>` is now legal for _any_ generic function-typed
expression `e`.
Because we no longer resolve PropertyAccess piecemeal, we no longer
report UNDEFINED_IDENTIFIER or UNDEFINED_PREFIXED_ELEMENT etc before
deciding to check if a tearoff is being made on a function-typed
element. The unfortunate side-effect here is some redundant
error-reporting. :( I've left TODOs.
Change-Id: I62106332e39d528cbd7cdfa5ec831dc56b394b52
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213800
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
In many files, there is a redundancy in importing
import 'package:compiler/src/common.dart'
and
import 'package:compiler/src/diagnostics/diagnostic_listener.dart'
I chose to remove the latter import.
Bug: https://github.com/dart-lang/sdk/issues/44569
Change-Id: Ia6c871080bf2d7c637694a4fe5cb1b84e540b789
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213851
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>