This CL adds `isWildcard` to `StructuralVariableBuilder` and allows type variables in functions and function types. It also removes them from scope so they can't be used.
Bug: https://github.com/dart-lang/sdk/issues/55655
Change-Id: I26237375480318dd0c9a01cb59b3426b783ca7be
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/372240
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Wildcard optional parameters aren't used anyways, so it doesn't matter if they have a default value.
This CL removes the error that's typically there.
Bug: https://github.com/dart-lang/sdk/issues/55655
Change-Id: Ie7286e1c3650fa347b1c28f1cc4ebd657cca33de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/371560
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
* Unqualified, out-of-scope static extension members are not
accessible.
* Locally scoped extension members shadow others.
* Static and instance extension members do not conflict.
Fixes https://github.com/dart-lang/sdk/issues/41268
Fixes https://github.com/dart-lang/sdk/issues/55848
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try,pkg-win-release-try
Change-Id: Icd618d044b3857efa24f365c6835d42c0022c176
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370323
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Sam Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Make tool (by default) give error when test entry specified in status
file does not exist. Make -w (by default) remove such entries.
Cleanup most status files, fixing a few entries containing `.dart` and
removing obsolete entries (i.e. entries pointing to nonexisting tests).
This should for instance have given an error in
https://dart-review.googlesource.com/c/sdk/+/370600 saying that the file
I specified didn't exist (in that I shouldn't have specified the `.dart`
part).
TEST=No tests, this is status file maintenance.
Change-Id: Ie977bf15dea2e3dad8d771fd3e99917317e975f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370886
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Previously, if a record literal had named fields, type inference of
the literal fields would happen as part of the process of
hoisting. This was a problem because the hoisting process requires
visiting the fields in reverse order, so as a result, the order in
which subexpressions were type inferred was the reverse of the order
in which they would be executed, leading to unsound type promotion
behavior.
Fixes#55914.
Bug: https://github.com/dart-lang/sdk/issues/55914
Change-Id: I2d8930e0e1d7579d065bfb850aa7472d28a8012c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369761
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
No client of the VM uses this flag, only tests, and this flag was always
set to false in AOT mode. Thus, remove uses of this flag and instead
always lazily create dispatchers as needed when resolving method names
in JIT mode.
Remove the implicit value of `allow_add` for some Resolver
static methods. For callers that previously depended on the implicit
`true` value (which includes the AOT precompilier), pass `true` for
uses in the compiler and pass `!FLAG_precompiled_mode` for uses in the
runtime. Assert that `allow_add` is false when these methods are invoked
from the precompiled runtime.
Remove Resolver static methods that are no longer used.
TEST=ci
Change-Id: Ib6a7354f7a859e86743c381513a4129c14895753
Cq-Include-Trybots: luci.dart.try:vm-linux-debug-x64-try,vm-linux-release-x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-release-x64-try,vm-aot-mac-release-arm64-try,vm-mac-debug-arm64-try,vm-mac-release-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366668
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Equal types should have the same hash, but they are not necessarily
identical.
Update the test to remove the identity check between a constant type and
a type constructed in runtime.
Change-Id: I0d6c6395c587391d3087c26b00fff36d645b33dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/368340
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Fix follow up comments with an async rethrow test.
Tests that wildcard patterns still work while mixed with wildcard variables.
Bug: https://github.com/dart-lang/sdk/issues/55652
Change-Id: If6ab4de68ff27ad51215427a7183f1aed7229947
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367501
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
I convert the `noSuchMethod` tests to (imho) simpler tests of what
property access of `e` or `d` or `D` would look like on an int, via
extension getters.
The noSuchMethod test as it was written cannot be executed at runtime,
because (as of Dart 2, I think, maybe earlier), property access on
expressions is a compile-time consideration. And I think as a compile-
time error test, it's hard to see what it's testing.
Change-Id: I5c0ca728e6e812b8f35adb80b288be351c4b076a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367461
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Added a little section for late wildcard variables too.
This CL tests mixing top-level wildcard declarations with local wildcard declarations and the non-shadowing, non-binding behaviour.
Bug: https://github.com/dart-lang/sdk/issues/55652
Change-Id: I72e7cfb1b2d80a3934af355579c36252881cf3fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367241
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Making language tests in small batches. These are very basic ones to test that you can have multiple local declarations named `_` in the same namespace without a collision error.
Bug: https://github.com/dart-lang/sdk/issues/55652
Change-Id: I4d00e9072ba745b363d68db72505c599953c41ad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366022
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Note that this is not a breaking change, since the CFE already
correctly flags the error condition.
Fixes#55734.
Bug: https://github.com/dart-lang/sdk/issues/55734
Change-Id: I5570e0840ce20c2a761d88f698b9876f7543bd8e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366680
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The expriment is now retired in Dart 3.5, and the flag
stops being valid.
Change-Id: I1ecb087d45b90e98a7f0d3c15a6c8038a1c6982e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365260
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
When analyzing the type test implied by a pattern, flow analysis uses
three variables to control promotion behavior:
- `matchFailsIfWrongType`, which indicates whether flow analysis needs
to account for the possible control flow path resulting from the
type test failing. (This is `false` for cast patterns, because in
the case where a cast pattern fails, an exception is thrown).
- `matchMayFailEvenIfCorrectType`, which indicates whether flow
analysis needs to account for the possible control flow path
resulting from the type test succeeding, but some other check
causing the match to fail. (This is `true` for most list patterns,
because the list pattern will fail to match if the list has the
wrong length).
(Note that `matchMayFailEvenIfCorrectType` doesn't account for the
fact that a pattern match might fail due to failure in a subpattern
match; this is automatically handled by the fact that flow analysis
walks through the complete pattern in the order in which it
executes.)
- `coversMatchedType`, which indicates whether the type test is
guaranteed to succeed due to a subtype relationship between the
matched value type and the type being tested (e.g. a `num x` pattern
is guaranteed to succeed if the matched value type is `int`).
In the case where `matchFailsIfWrongType` is `true`,
`matchMayFailEvenIfCorrectType` is `true`, and `coversMatchedType` is
`false`, flow analysis must account for the fact that there are two
ways that the pattern match might fail: the type test might fail, or
the type test might succeed but then the pattern match might fail for
some other reason.
Before this change, this was done incorrectly, and flow analysis only
accounted for the possibility of the type test failing.
Fixes#55543.
Bug: https://github.com/dart-lang/sdk/issues/55543
Change-Id: I86603ec5f940402313f32177212b7960878db97f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364942
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This reverts commit cd2c566bcf.
Reason for revert: Updating to not remove field used by Flutter engine.
Original change's description:
> Revert "Tweak `expect.dart` library."
>
> This reverts commit ff5f391c0a.
>
> Reason for revert: The expect library is used by Flutter engine, and some of its tests use assertStatementsEnabled. There should be a migration path that doesn't require an atomic change, like adding the replacement api before removing the old one.
>
> Original change's description:
> > Tweak `expect.dart` library.
> >
> > Make API more consistent for a few methods.
> > Reduce the number of language features used in tests:
> > * Never iterating an iterable, always converting it
> > using `.toList()` first and iterating using indices
> > (fx `setEquals`).
> > Also require a `List` in places where an `Iterable`
> > wasn't necessary.
> > * Avoid doing complicated computations that are also
> > used for the error message. Do simple check first,
> > then recompute to get better error messages
> > (fx `allDistinct`).
> >
> > Renamed some rarely used members for consistency
> > (`stringContainsInOrder`->`containsInOrder`,
> > where other string-contains functions just start
> > with `contains`, and `containsOneOf` -> `containsAny`
> > to match `Iterable.any` phrasing, and also it accepts
> > if containing at least one, not precisely one.)
> >
> > Removed a function that wasn't used anywhere.
> >
> > Moved `assertStatementsEnabled` to `variations.dart` as `asserts`.
> > Removed `typeAssertionsEnabled` and `checkedModeEnabled`. The former used in one place, where it was replaced with `checkedImplicitDowncasts` from `variations.dart`, the latter wasn't used anywhere.
> >
> > Deprecates `package:expect/minitest.dart`. It was never intended
> > to be used for new tests, only as a help to convert existing tests
> > written against `package:unit_test`.
> > All existing imports marked as `// ignore: deprecated_member_use`.
> >
> > Change-Id: I07e21d4c0f3ccf11b82ee34af2668fdbb22264d2
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352360
> > Reviewed-by: Slava Egorov <vegorov@google.com>
> > Reviewed-by: Ömer Ağacan <omersa@google.com>
> > Reviewed-by: Nate Bosch <nbosch@google.com>
> > Reviewed-by: Stephen Adams <sra@google.com>
> > Commit-Queue: Lasse Nielsen <lrn@google.com>
>
> Change-Id: I360b4347470a0bb2b63c3108e2b83ee2a771bf3f
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362020
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Reviewed-by: Ömer Ağacan <omersa@google.com>
> Reviewed-by: Stephen Adams <sra@google.com>
> Reviewed-by: Leaf Petersen <leafp@google.com>
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Commit-Queue: William Hesse <whesse@google.com>
CoreLibraryReviewExempt: Reland
Change-Id: I53db40edc0733842a008839c3913d51c885e39ab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362502
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
The parser didn't support 'new' as identifier in this context.
The CL also adds the reporting of tear-offs as metadata for the CFE.
This was already handled by the analyzer.
Change-Id: I7ab5868fa83e5f216d0e7be7ae9cec4a2c865e80
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364480
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Multitests of compile-time errors should be converted to static
error tests, so they don't run on runtime configurations.
Static error tests also test for all the static errors,
their positions, and error message, in a single test run.
This test is currently failing on the common front end,
and on all runtimes, and passing on the analyzer. The
change keeps the failure on common front end by adding
expectations for an error to be reported at the right places.
Bug: https://github.com/dart-lang/sdk/issues/54153
Change-Id: Ic64961f6e0e575ec60626d4f70a0fdc5d71d024e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363085
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: William Hesse <whesse@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This reverts commit ff5f391c0a.
Reason for revert: The expect library is used by Flutter engine, and some of its tests use assertStatementsEnabled. There should be a migration path that doesn't require an atomic change, like adding the replacement api before removing the old one.
Original change's description:
> Tweak `expect.dart` library.
>
> Make API more consistent for a few methods.
> Reduce the number of language features used in tests:
> * Never iterating an iterable, always converting it
> using `.toList()` first and iterating using indices
> (fx `setEquals`).
> Also require a `List` in places where an `Iterable`
> wasn't necessary.
> * Avoid doing complicated computations that are also
> used for the error message. Do simple check first,
> then recompute to get better error messages
> (fx `allDistinct`).
>
> Renamed some rarely used members for consistency
> (`stringContainsInOrder`->`containsInOrder`,
> where other string-contains functions just start
> with `contains`, and `containsOneOf` -> `containsAny`
> to match `Iterable.any` phrasing, and also it accepts
> if containing at least one, not precisely one.)
>
> Removed a function that wasn't used anywhere.
>
> Moved `assertStatementsEnabled` to `variations.dart` as `asserts`.
> Removed `typeAssertionsEnabled` and `checkedModeEnabled`. The former used in one place, where it was replaced with `checkedImplicitDowncasts` from `variations.dart`, the latter wasn't used anywhere.
>
> Deprecates `package:expect/minitest.dart`. It was never intended
> to be used for new tests, only as a help to convert existing tests
> written against `package:unit_test`.
> All existing imports marked as `// ignore: deprecated_member_use`.
>
> Change-Id: I07e21d4c0f3ccf11b82ee34af2668fdbb22264d2
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352360
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Reviewed-by: Ömer Ağacan <omersa@google.com>
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Reviewed-by: Stephen Adams <sra@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
Change-Id: I360b4347470a0bb2b63c3108e2b83ee2a771bf3f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362020
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: William Hesse <whesse@google.com>
Make API more consistent for a few methods.
Reduce the number of language features used in tests:
* Never iterating an iterable, always converting it
using `.toList()` first and iterating using indices
(fx `setEquals`).
Also require a `List` in places where an `Iterable`
wasn't necessary.
* Avoid doing complicated computations that are also
used for the error message. Do simple check first,
then recompute to get better error messages
(fx `allDistinct`).
Renamed some rarely used members for consistency
(`stringContainsInOrder`->`containsInOrder`,
where other string-contains functions just start
with `contains`, and `containsOneOf` -> `containsAny`
to match `Iterable.any` phrasing, and also it accepts
if containing at least one, not precisely one.)
Removed a function that wasn't used anywhere.
Moved `assertStatementsEnabled` to `variations.dart` as `asserts`.
Removed `typeAssertionsEnabled` and `checkedModeEnabled`. The former used in one place, where it was replaced with `checkedImplicitDowncasts` from `variations.dart`, the latter wasn't used anywhere.
Deprecates `package:expect/minitest.dart`. It was never intended
to be used for new tests, only as a help to convert existing tests
written against `package:unit_test`.
All existing imports marked as `// ignore: deprecated_member_use`.
Change-Id: I07e21d4c0f3ccf11b82ee34af2668fdbb22264d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352360
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
With nested `async*` functions, the state of whether we're in an
`async*` function should be restored as the previous state after leaving
the nested function, instead of as `false`.
Fixes#55397.
Change-Id: I5f2a964847ae34e98584f3adad6df7857b81e474
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361600
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Product builds of gen_snapshot are used by dart cli tools. So if we are to allow --enable-asserts for 'dart compile' commands, we need to allow this flag in product mode.
BUG=dartbug.com/53343
TEST=ci
Change-Id: I6252b6ee42ed45a25df2046f4a6642c880e8ee14
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361122
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Fixes#55347.
Change-Id: I9ced2a4c06e6cb9714dc47e3661f5582c70cdeb0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361063
Reviewed-by: Erik Ernst <eernst@google.com>
Reviewed-by: Jackson Gardner <jacksongardner@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
This CL makes the following improvements (suggested in the code review
of https://dart-review.googlesource.com/c/sdk/+/356303):
- Add parenthetical comment "(Testing this case here. Otherwise
continued below.)", to reduce confusion for a reader reading the
tests for the first time.
- In all test cases using a promotable variable `o`, declare `Object?
o;` first, then assign `o = ... as Object?;`. This makes the test
cases more symmetrical, since `o = ... as Object?;` now appears in
every test case, rather than getting coalesced with the variable
declaration in some test cases but not others.
- Consistently use `e` rather than `E` to refer to the whole
expression being tested.
- Expand on the explanation for how each test case matches up to the
type metavariables K, T1, T2, etc., and why the expected result
occurs.
- Remove tickmarks around type metavariables.
- Clarify that the type S is chosen, rather than T, only when the
feature is enabled.
Change-Id: I149b323daeac9fc44104681370cea33ee010faa4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357204
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In the front end, type inference of an expression always takes place
with respect to a type schema (the "context"). In the analyzer, type
inference of an expression sometimes takes place with respect to a
context, but sometimes takes place with respect to no context at all;
the latter circumstance arises when the analyzer uses its standard
AstVisitor mechanism to call one of the visit methods in the
ResolverVisitor class, and so the visit method's contextType argument
takes on the value null. Because of this I am calling this situation a
"null context".
In all the circumstances where the analyzer infers an expression using
a null context, the front end infers the same expression using a
context of _. Furthermore, prior to this change, all but one of the
analyzer's visit methods treated a null context the same as they
treated a context of _. The one exception was visitAwaitExpression: in
this method, if the context was the null context, then the analyzer
analyzed the await expression's subexpression using a context of _;
otherwise, it analyzed it using a context of FutureOr<_>. Whereas the
front end, lacking any notion of a "null context", analyzes the await
expression's subexpression using a context of FutureOr<_> in the same
circumstances.
This change brings the analyzer behavior into line with the front end.
Fixes https://github.com/dart-lang/language/issues/3648.
Bug: https://github.com/dart-lang/language/issues/3648
Change-Id: Ifd77988010d4387ce48eaa20dff4356beec03753
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357521
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The tests for the language feature `inference-update-3` are adjusted
to verify that the following hold true for an if-null expression of
the form `e1 ??= e2`:
- If the static type of `e2` is not a subtype of the write type of
`e1`, but it is assignable via a coercion, then the coercion is
performed, and the coerced type of `e2` is used to compute the
static type of the whole `??=` expression.
- If `e1` is a promoted local variable, then coercions are performed
based solely on the declared (unpromoted) type of `e1`.
These behaviors apply regardless of whether feature
`inference-update-3` is enabled; accordingly, this commit updates both
the `_test.dart` and `_disabled_test.dart` variants of the tests. I've
manually verified that even with the work on `inference-update-3`
reverted, the `_disabled_test.dart` tests continue to pass, so we can
be reasonably certain that these behaviors pre-date the work on the
`inference-update-3` feature.
Note: the diff is large due to the fact that the front end has 6
different code paths for handling `??=`, depending on the form of the
LHS, so to make sure that we have adequate test coverage, there are
tests for every possible LHS form. However, the diffs for all the
tests are pretty much the same except for
`if_null_assignment_local_disabled_test.dart` and
`if_null_assignment_local_test.dart`, which have extra test cases to
cover promotion behaviors.
Bug: https://github.com/dart-lang/language/issues/1618
Change-Id: I711d62d9dc00fc20a2efd3967d60066d9bfaec03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/356303
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL introduces a way to mark all instances of a class as deeply
immutable.
In order to statically verify that all instances of a deeply immutable
class are immutable, a deeply immutable classes must have the following
properties:
1. All instance fields must
1. have a deeply immutable type,
2. be final, and
3. be non-late.
2. The class must be `final` or `sealed`. This ensures no
non-deeply-immutable subtypes are added by external code.
3. All subtypes must be deeply immutable. This ensures 1.1 can be
trusted.
4. The super type must be deeply immutable (except for Object).
Note that instances of some classes in the VM are deeply immutable
while their class cannot be marked immutable.
* SendPort, Capability, RegExp, and StackTrace are not `final` and
can be implemented by external code.
* UnmodifiableTypedDataViews do not have a public type. (It was
recently deprecated.)
See runtime/docs/deeply_immutable.md for more details.
Use case:
This enables attaching a `Dart_FinalizableHandle` to a deeply immutable
object and the deeply immutable object with other isolates in the same
isolate group.
(Note that `NativeFinalizer`s live in an isolate, and not an isolate
group. So this should currently _not_ be used with `NativeFinalizer`s.
See https://github.com/dart-lang/sdk/issues/55062 for making a
`NativeFinalizer.shared(` that would live in an isolate group instead
of in an isolate.)
Implementation details:
Before this CL, the `ImmutableBit` in the object header was only ever
set to true for predefined class ids (and for const objects). After
this CL, the bit can also be set to true for non const instances of
user-defined classes. The object allocation and initialization code has
been changed to deal with this new case. The immutability of a class is
saved in the class state bits. On object allocation and initialization
the immutability bit is read from the class for non-predefined class
ids.
TEST=runtime/tests/vm/dart/isolates/fast_object_copy2_test.dart
TEST=runtime/vm/isolate_reload_test.cc
TEST=tests/lib/isolate/deeply_immutable_*
Bug: https://github.com/dart-lang/sdk/issues/55120
Bug: https://github.com/dart-lang/sdk/issues/54885
Change-Id: Ib97fe589cb4f81673cb928c93e3093838d82132d
Cq-Include-Trybots: luci.dart.try:vm-aot-android-release-arm64c-try,vm-aot-android-release-arm_x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try,vm-appjit-linux-debug-x64-try,vm-asan-linux-release-x64-try,vm-checked-mac-release-arm64-try,vm-eager-optimization-linux-release-ia32-try,vm-eager-optimization-linux-release-x64-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-ffi-qemu-linux-release-arm-try,vm-ffi-qemu-linux-release-riscv64-try,vm-fuchsia-release-x64-try,vm-kernel-linux-debug-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-linux-debug-ia32-try,vm-linux-debug-x64-try,vm-linux-debug-x64c-try,vm-mac-debug-arm64-try,vm-mac-debug-x64-try,vm-msan-linux-release-x64-try,vm-reload-linux-debug-x64-try,vm-reload-rollback-linux-debug-x64-try,vm-ubsan-linux-release-x64-try
Cq-Include-Trybots: dart-internal/g3.dart-internal.try:g3-cbuild-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354902
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
In the following expression types, the static type is computed using
the least upper bound ("LUB") of their subexpressions (adjusted as
appropriate to account for the null-shorting behaviors of `??` and
`??=`):
- Conditional expressions (`a ? b : c`)
- If-null expressions (`a ?? b`)
- If-null assignments (`a ??= b`)
- Switch expressions (`switch (s) { p0 => e0, ... }`)
This can lead to problems since the LUB computation sometimes produces
a greater bound than is strictly necessary (for example if there are
multiple candidate bounds at the same level of the class hierarchy,
the LUB algorithm will walk up the class hierarchy until it finds a
level at which there is a unique result). For a discussion of the kind
of problems that can arise, see
https://github.com/dart-lang/language/issues/1618.
This change improves the situation by changing the analysis of these
four expression types so that after computing a candidate static type
using LUB, if that static type does not satisfy the expression's
context, but the static types of all the subexpressions *do* satisfy
the expression's context, then the greatest closure of the context is
used as the static type instead of the LUB. This is the algorithm
proposed in
https://github.com/dart-lang/language/issues/1618#issuecomment-1507241494.
This is theoretically a breaking change (since it can change code that
demotes a local variable into code that doesn't, and then the demotion
or lack of demotion can have follow-on effects in later code). So it
is implemented behind the `inference-update-3` experiment
flag. However, in practice it is minimally breaking; a test over all
of google3 found no test failures from turning the feature on.
Since one of these expression types (switch expressions) is
implemented in `package:_fe_analyzer_shared`, but the other three are
implemented separately in the `package:analyzer` and
`package:front_end`, this change required modifications to all three
packages. I've included tests for the new functionality, following the
testing style of each package. I've also included a comprehensive set
of language tests that fully exercises the feature regardless of how
it's implemented.
Since `package:front_end` has many different implementations of `??=`
depending on the form of the left hand side, I've tried to be quite
comprehensive in the language tests, covering each type of assignable
expression that might appear to the left of `??=`.
Change-Id: I13a6168b6edf6eac1e52ecdb3532985af19dbcdf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353440
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
