This is follow-up to 56403a0d35.
Change-Id: I222c04fd4d41e272eeb3e8fd62c55035eee1c12c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215143
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
The associated `unawaited_futures` lint triggers for expressions
of type `Future?` as well, so we should allow the workaround to
handle such expressions.
This change makes a static function more permissive, and is not expected
to be breaking in any way.
(It does mean that you need Dart 2.15.0 to use the function with
nullable arguments. I've changed the annotation to say `@Since("2.15")`.
That means anyone using a 2.15 SDK should assume that they need a 2.15
SDK to use it, and someone using a 2.14 SDK will not see the argument
as nullable. If anyone uses `@Since` annotations for anything at all.)
Change-Id: Ib2da4b353104cc88a834208a6ebd788ae55b4544
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214406
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@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>
Fixes#47190
TEST=None, only markdown files where edited.
Change-Id: Ife204f9c792b6bce30d0cd7bf2260ced11c8f2b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213049
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Change-Id: I73bfdd310af6df6cc1d62311e155fc432b84165d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212567
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Auto-Submit: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Per breaking change #45451 we are removing support for dart-ext:
style native extensions from the Dart VM.
This CL removes the associated VM code, tests and samples. It also ports
a single test which used dart-ext: import to use FFI instead.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/45451
Change-Id: Iae984bce32baf29a950b5de1323939006a217b94
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212050
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Change-Id: Ia4a9ffa1b4e27abcea66dca985d099f9fef75790
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211400
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Michael Thomsen <mit@google.com>
Previously, initializers of implicitly typed variables did not
contribute to the SSA tracking performed by flow analysis (see
https://github.com/dart-lang/language/issues/1785). This change fixes
the bug, however the fix is conditioned on the "constructor tearoffs"
language feature to avoid compatibility issues (we don't want someone
to publish a package taking advantage of the fix, without realizing
that it makes their package unusable on older SDKs).
TEST=standard trybots
Bug: https://github.com/dart-lang/language/issues/1785
Change-Id: I1143440c7a9795b059e8f4b84e3f4125cd80732c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211306
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Previously, when encountering identifiers in metadata on a class's
type parameter, the analyzer would resolve them using the type
parameter scope, but then fall back on using implicit `this`. The CFE
would resolve them using the class body scope. In both cases, the end
result was that the annotation could refer to static class members.
This change brings the behavior of both the analyzer and the CFE in
line with the spec, by preventing the use of implicit `this` in these
annotations, and resolving them in the type parameter scope.
This is not expected to break any code in practice, because
annotations on type parameters are rare, as are annotations referring
to static class members, and the overlap between these two should be
negligibly small.
Fixes https://github.com/dart-lang/language/issues/1790.
Bug: https://github.com/dart-lang/language/issues/1790
Change-Id: Ibe5a421e04a53d29074a8b1509e1390658ed72e5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210040
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Change-Id: I860fbe6b821061695c50319204d8d6ba9c98a839
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209109
Auto-Submit: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Kevin Moore <kevmoo@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Removes the lazy loading of the underlying type in LazyJSTypes.
As such, this removes the need to keep AnonymousJSType and
LazyJSType separate, and is therefore refactored to
PackageJSType. Similarly, subtyping is fixed such that
PackageJSTypes are all subtypes of each other.
Change-Id: If489defdbeb5cb932db802a7d146ad2fc393b12c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207982
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This effectively enables ES6 language features in Dart2JS by default.
Also adapts some tests to expect ES6 Method Definition syntax.
Change-Id: Iec36fbf9d22afd1083f7560a16fa73fbf15fb85c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205741
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Also apply new formatting style to dart format section
Change-Id: I5e7ad454ff2794dc98eb4f1868416beb45b1c68e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206340
Auto-Submit: Kevin Moore <kevmoo@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Change-Id: I866378cba43db7f559e37d3c0bf163843f74d186
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204941
Auto-Submit: Kevin Moore <kevmoo@google.com>
Commit-Queue: Kevin Moore <kevmoo@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
The `unawaited` function in `dart:async` is intended for use with the `unawaited_futures` lint which is hopefully going to be part of the Dart recommended set of lints.
The `ignore` extension method is there to provide an alternative if you even want to ignore errors from a future. By having both, it makes the distinction clearer and makes it easier to not think one can be used for everything.
Change-Id: Ib96ed5ff64ead4b228721e5210efa82f76119c9f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/200428
Reviewed-by: Jacob Richman <jacobr@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
