These NoSafepointScopes are active for only one load/store where there is little need to guard against someone adding an allocation. They have been observed to take up to 15% of program execution in debug builds.
TEST=ci
Change-Id: I923baa28a3a72decacbfcdec3331ce9c7c620b67
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275540
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Now that 9df6656aa9 has appropriately propagated and the build rules in
google3 have been updated, re-add checks to ensure that the empty
section used to pad the original header exists and that the new header
is smaller than the old header.
Bug: https://github.com/dart-lang/sdk/issues/49783
Change-Id: I5b8b31bf9edf4814686eb7928457a9a7d53c0727
Cq-Include-Trybots: luci.dart.try:dart-sdk-mac-try,dart-sdk-mac-arm64-try,pkg-mac-release-arm64-try,pkg-mac-release-try,vm-kernel-mac-release-arm64-try,vm-kernel-mac-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275622
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Previously, the client had to know that the relational operator should
be looked up in the matched value type. Now the shared analysis logic
requests the lookup and supplies the appropriate type.
It's a small change, and one might argue that it doesn't really move
around very much business logic, but it makes the tests more readable
so I think it's worth it.
Change-Id: I936d5f5f929f11800efe25974334c898c7e1072d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275360
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This change is necessary for large strings because otherwise we hit V8's maximum argument limit to a function.
Change-Id: I2473d1c5acd62f16d509752c437678c697e7ebeb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275480
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
This enables the front end to skip the old-style (enum-based)
exhaustiveness checking algorithm when pattern support is enabled,
because with pattern support enabled, switches on enums are required
to be exhaustive (this will be checked by the new exhaustiveness
checking algorithm).
That in turn means that in the future, when we remove support for
language versions that lack patterns support, we will be able to
remove the old-style exhaustiveness checking algorithm.
This change has a small effect on code generated by the WASM back-end
(the only back-end that uses `isExplicitlyExhaustive`): for a switch
statement that is exhaustive *and* has an unreachable `default`
clause, after testing all the cases, the WASM back-end will generate a
branch to the `default` case. Previously it would instead generate an
`unreachable` instruction. There should be no behavioural difference
because the instruction in question is unreachable in both cases.
Also, there should be negligible code size difference because the body
of the `default` case is being emitted either way.
Bug: https://github.com/dart-lang/sdk/issues/50419
Change-Id: Id6bd7d9a540cb1b4d9c3624db8ff494438276bea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274924
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
A desired feature for flow analysis of patterns is that the matched
value type of one subpattern may depend on promotions from previous
patterns. For example, we want this to work:
int? x = ...;
if (x case null || < 0) ...;
This means that although the type of the scrutinee is `int?`, after
the subpattern `null` has been processed, type promotion should
promote the matched value type to `int`, so that the subpattern `< 0`
doesn't report an error.
This requires changing the API of the shared patterns analysis logic,
so that the client is no longer responsible for passing around the
matched value type. Instead, flow analysis keeps track of it and
provides it to the client when requested.
In follow-up CLs I'll add the necessary logic to flow analysis to
actually promote the matched value type in situations like the example
above.
Change-Id: I6ce66962af32f9bd93bfe4082ba256de627d3cc6
Bug: https://github.com/dart-lang/sdk/issues/50419
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274942
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
The test stacktrace_current compares two stack traces by masking any
line numbers.
With dart2wasm, V8 shows function offsets instead of line numbers, in
hex, which causes the test to fail with unrelated changes.
This updates the regex to mask hex numbers as well, making the test
stable with unrelated dart2wasm changes.
Change-Id: I8dd951d4bf29fe39b6ec5d8de7bf2c9c37a5b5b3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275600
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
This updates the exhaustiveness implementation to have specific static
built-in types for nullableObject (the top) and its underlying nonNullableObject,
nullType and its underlying neverType. In the previous encoding, the top
wasn't nullable (if you queried the isNullable property) but was still
assumed to contain `Null` in other parts of the code.
With this change, the top space is now an ExtractSpace based on
StaticType.nullableObject, the empty space is an ExtractSpace based on
StaticType.neverType and record spaces are based on
StaticType.nonNullableObject.
The StaticType is now split into a StaticType interface and a
StaticTypeImpl implementation class for the non-built-in types. This
prepares for integrating the exhaustiveness checking with the analyzer
and CFE where the properties of the sub/supertype relation and fields of
the StaticType needs to be computed lazily.
Change-Id: I5a6919d7cba356f9bc8ac3f69fd3ac2b41319e9b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274020
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
These are scattered changes to get to type inferrence.
- Add some impact tracking for used record types
- Add RecordTypeInformation and FieldInRecordTypeInformation
- Add a simple test to show inference is currently very conservative.
Change-Id: Icb81033b11588c1bddd01c8c5fcf69950fdb77e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275161
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
TEST=ci, local qemu
Change-Id: I3321264b524d52e5a63a32f70b62f27182ebc247
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/273833
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
`null` was being included in the set of called nodes and this was causing members normally called once to not be inlined.
Change-Id: Ie42302e47691bb924dea1e54b82e08072c0ecd7b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275122
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Starting from ba6be821c99db09b0ef2689dea8f0cb863c47ff5 (11.0.194), V8
enforces type equivalence according to the canonical iso-recursive
types for functions imported from other modules or constructed using
`WebAssembly.Function`, which means that to match such a type, a
function type declared in a Wasm module must be declared in a
singleton rec group.
To be compatible with this new canonicalization scheme, we define the
function types for all imported functions each in their own rec group
separately from other types.
Change-Id: I166b4b7d1c8fa48638f816f874f737536a61f15d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274388
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
This avoids reliance on the distinctness of the Wasm types.
Change-Id: I23762c674fcf8b2101da30d91f0b6db9ae947d79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274681
Reviewed-by: Joshua Litt <joshualitt@google.com>
It was returning library's index which is an unstable
value. This instability could cause `Precompiler::HasApiUse`
to stop returning `true` after `Precompiler::DropLibraries` even
if library was added to the `api_uses_` set. This in turn could cause
`Precompiler::PruneDictionaries` to drop library entries it should
not have dropped.
TEST=added assertion that verifies stability of the set
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try
Change-Id: I0685bd75562f83e2b9d8b3a03fa410ba218df2ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275241
Reviewed-by: Tess Strickland <sstrickl@google.com>
Auto-Submit: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
The definition of flatten was adjusted in
https://github.com/dart-lang/language/pull/2696
such that it better preserves the type information when the type of `e`
in `await e` is a type variable. This CL changes the test to expect
the behavior of the newly specified flatten.
The test has been renamed to 'await_flatten_test.dart'.
Change-Id: Iaf67a53cd3cd181bcb3eb6e85beca7cc1af4d34a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274682
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
This reverts commit c09f790d37.
Reason for revert: CI failures
Original change's description:
> [VM/CLI] Remove dartdev.dill
>
> Incompatible VM flags will no longer break the CLI when running from an
> AppJIT snapshot, so the fallback logic is no longer required. This CL
> thus removes dartdev.dill and the fallback logic.
>
> Relevant past CLs: https://dart-review.googlesource.com/c/sdk/+/157601
> and https://dart-review.googlesource.com/c/sdk/+/178300
>
> Fixes https://github.com/dart-lang/sdk/issues/50504
>
> TEST=I tried running `out/ReleaseX64/dart --observe --sound-null-safety test.dart`
> and `out/ReleaseX64/dart --observe --no-sound-null-safety test.dart` and
> both worked.
>
> Change-Id: I5cdcfbccf71ec557964014fdb80733b4a7c76b4d
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274520
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Commit-Queue: Derek Xu <derekx@google.com>
TBR=bkonyi@google.com,derekx@google.com,dart-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I5117f990dfabf93f5a9bae56098831280845e84e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275181
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
I previously thought that the only possible situation where a switch
statement over a valid type could be exhaustive without containing any
cases was if the scrutinee type was the empty record type (`()`). But
that isn't true at all:
- The empty record type is inhabited by empty record objects, so such
a switch statement would not be exhaustive after all.
- It is possible for the user to create a type that can be
exhaustively switched over with zero cases: by creating an abstract
sealed class without any subclasses.
In the latter case, I think it makes the most sense to treat the code
after the switch as unreachable, because that's the normal behaviour
of a switch over an exhaustive type with no `break`s. It is sound to
do so because the type is uninhabited, therefore the body of the
switch statement itself will never be reached.
Bug: https://github.com/dart-lang/sdk/issues/50419
Change-Id: Ibc0a21226f25ae155db994343874354d5b8e4f7d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274621
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This boolean tells the analyzer and front end whether it is required
to run the exhaustiness algorithm on the switch statement (and to
report an error if the switch isn't exhaustive).
Bug: https://github.com/dart-lang/sdk/issues/50585
Change-Id: I8c95e563bd59a83cf5e1b94170af5c4f8b5c6496
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274925
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This simplifies the shared TypeAnalyzer code by avoiding a lot of null
checks.
This required modifying a few analyzer code paths that didn't
previously initialize FlowAnalysis so that they now do.
Change-Id: Ie306d3ac94c4ca00d211e9cd038fb0b001996747
Bug: https://github.com/dart-lang/sdk/issues/50419
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274940
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL changes the Dart grammar in Dart.g such that it contains all
the grammar changes applied to the patterns proposal since the previous
update of Dart.g.
Change-Id: I9b5f0d9a092d30ce0055db99da5fdbe3b9b1d5dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275002
Reviewed-by: William Hesse <whesse@google.com>
Auto-Submit: Erik Ernst <eernst@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
