This was added before null safety, and before we had fully
defined the difference between Null, Bottom, and Never types.
I believe now this and Never.nonNullable are equivalent and
the distinction is no longer important to make. Hence, I'm
deleting it to reduce tech debt.
Originally this was added in https://dart-review.googlesource.com/c/sdk/+/88961
Change-Id: I64b3a8b01833bc60305eaecf430bfb249c8d2c98
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301820
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
In https://dart-review.googlesource.com/c/sdk/+/299400, the parser was
adjusted so that it no longer accepts `when` and `as` as the names for
variable patterns in cases where there is a possible ambiguity
(e.g. `int when` is not accepted as a pattern because `int` is a
legitimate pattern, therefore `when` could introduce a guard
clause). This change further prohibits `when` and `as` from being the
names of variable patterns or identifier patterns even in the case
where there is no ambiguity. This is in line with the discussion at
https://github.com/dart-lang/sdk/issues/52199#issuecomment-1526297771,
and the spec change at
https://github.com/dart-lang/language/pull/3033.
Three new error codes are introduced, to cover the three circumstances
in which `when` or `as` might be used illegally: in a declared
variable pattern, in an assigned variable pattern, or in an identifier
pattern. I've also added analyzer tests to ensure that the parser
recovers from these errors nicely. Unfortunately, nice error recovery
is only feasible in the non-ambiguous cases.
I've also updated the language test expectations in
`tests/language/patterns/version_2_32_changes_error_test.dart` to
reflect the new error messages, and added a few more examples of uses
of `when` and `as` that are still permitted.
Fixes#52260.
Bug: https://github.com/dart-lang/sdk/issues/52260
Change-Id: I229f627aa639659c30b83c74895759207da279f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301482
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I'm actually not sure we are doing the right thing for general
aliases (that can now be nested arbitrarily deep), but at least
this commit avoids throwing an exception.
Change-Id: Ide3f7035b476f79fff5c542e2ddbb342045a874e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301983
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Ilya Yanok <yanok@google.com>
Null-aware calls, like `v?.extMethod()` don't require `v` to be
non-nullable, even if `extMethod` was declared on a non-nullable type.
Tested: added a new test.
Change-Id: I113ecde21e480bcd467367d0954b721c2ad9f7e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301982
Reviewed-by: Paul Berry <paulberry@google.com>
It looks like it's failing as a result of my previous changes
to make public function/method arguments nullable by default.
I probably missed it, since it doesn't run with assertions
enabled.
Change-Id: Ifcf045d778302a0be771c3a75c94cec97cbf8060
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301981
Reviewed-by: Paul Berry <paulberry@google.com>
Previously type tests involving type parameter types would
be replaced with native primitive tests when the type parameter
was bounded by a type with a native representation. This isn't
always correct because the type parameter can always be inhabited
by the bottom type at runtime. So code like `x is T` would be true
when `T` is instantiated as `Never` and `x` is any primitive value
like a number, string, or bool.
This change removes the incorrect optimization that allowed type
parameters to be replaced with their bound when that bound was
represented by a native type when performing an `is` operation.
Fixes: https://github.com/dart-lang/sdk/issues/52243
Change-Id: I57cebef7bb533d71831ef84415b3d91369758476
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/300820
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
Our helper function to detect whether a null-assertion was required
didn't include a case to check for record types.
The null-assertion flag is likely to go away soon, since it's
only valuable for mixed applications.
Fixes#52276
Change-Id: Ief4515b8c3eaae5343012da4220e6051bb5a2f19
Fixed: 52276
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301680
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Required for upcoming deferred loading changes.
Our previous only stored this resolution logic for all componets except the
current component, which resulted in some empty deferred loads when referencing
modules in the main component.
Also adds a small type signature update missed in a previous commit.
Change-Id: I8511a39b26e1864919cc4882a6c008d2010354a2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/299381
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Currently the `InstanceGet` node result type for for
`Completer<bool>.future` is `Future<bool> Function()`, but it should be
`Future<bool>`.
This causes problems in CL 301020 where we generate temporaries for
nested `await` expressions and use the expression type for the types of
those temporaries. Incorrect expression type in `completer.future`
causes a temporary with incorrect type to be generated.
Change-Id: Ib8193c66afee9454a275c00fb958c11fd35cd3eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301382
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
When compiling `compile.dart` 74054 non-const scopes are created;
~78% have empty locals and ~99% have empty setters.
This CL creates the maps lazily instead, thus potentially saving ~130k
map creations (and possibly an unknown number of lookups in empty maps
etc).
In measurements (on AOT when compiling `compile.dart`) this has resulted
in changes in runtime ranging from -1.81601% +/- 1.39701% to
-4.60653% +/- 1.68463%, the latest run gave this:
Difference at 95.0% confidence
-0.151 +/- 0.0557737
-3.90231% +/- 1.44137%
(Student's t, pooled s = 0.0871402)
Change-Id: Ic65eeca253dccb871585c221798b59852de80616
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301064
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This moves the implementation of BodyBuilderContext into the subclasses
where the methods are supported. Additionally a
BodyBuilderDeclarationContext for the implementation based on the
(enclosing) declaration/class builder.
Change-Id: I5084e87ae0c0882db94e4021971d86f8a149daa4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301360
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Currently every FlowModel creates a new empty map that's just supposed
to be empty. When compiling `compile.dart` (from the CFE) this creates
more than 200,000 maps for seemingly no reason.
This CL removes it, thus saving the creation of (...instrumenting the
platform...) 229,472 maps when compiling `compile.dart` (from the CFE).
Thinking it was done to avoid some polymorphism I have gone over the
created flowgraphs for the file in both JIT and AOT and found only
improvements.
AOT compiled `compile.dart` then compiling itself improves by ~3.5%:
```
Difference at 95.0% confidence
-0.1365 +/- 0.0576111
-3.55191% +/- 1.49912%
(Student's t, pooled s = 0.090011)
```
Change-Id: Ifdbb57e9aa3c23b2af512a2104aaf6caf72831ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301061
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This adds individual [BodyBuilderContext] classes for the different
contexts and passes these at the root of the BodyBuilder creation.
Currently these are simple subtypes [BodyBuilderContext] but the plan
is to move implementation into the subclasses where the functionality
is actually supported.
Change-Id: I8ea22c5f563d9fa539cbd17ed02c919647a1aecd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301000
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Johnni Winther