Running dart code on mutator thread outside of isolate still should follow limits on number of concurrent mutators in the vm.
Also this fixes inconsistency when entering isolate group as mutator, where original worker was marked as blocked while thread was actually running dart code. That inconsitency showed up as sporadic crash on isolate_group_shared_init_test with increased number of spawned isolates.
TEST=isolate_group_shared_init_test
BUG=https://github.com/dart-lang/sdk/issues/60877
Change-Id: I8917be903bb5517940dad3e5dab143d5ed5fdf79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432900
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Add a mutex to guard execution of vm:shared field initialization.
TEST=isolate_group_shared_init_test
BUG=dartbug.com/60699
Change-Id: If544351fc26bfcc7fb9703954efe785989d488bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431742
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
When an `is` test is trivially satisfied (i.e. `expr is T`, when the
static type of `expr` is a subtype of `T`), the `is` test is
guaranteed by soundness to evaluate to `true`, so any code path that
follows from the `is` test evaluating to `false` is unreachable.
This reasoning wasn't valid prior to sound null safety, because in
mixed mode programs, it was possible for an expression to evaluate to
`null` even if its static type wasn't nullable, and hence `expr is T`
might evaluate to `false` even if the static type of `expr` was a
subtype of `T`. So this change is gated on the `sound-flow-analysis`
language flag (which is enabled in Dart 3.9).
Fixes https://github.com/dart-lang/sdk/issues/60718.
Change-Id: I66a65580b738162f23b6fb468b71fcac66bfbb95
Bug: https://github.com/dart-lang/sdk/issues/60718
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431740
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Previously, when assiging to a local variable that was promoted, if
the newly assigned value was not compatible with any of the promotions
(i.e., the variable was fully demoted back to its declared type), then
the set of types of interest was cleared.
This behavior was not documented anywhere in the spec, and it seems
oddly inconsistent to me; as far as I can tell, flow analysis doesn't
clear types of interest in any other circumstances. I've looked
through git history as well as my personal notes, and I've been unable
to find any justification for this behavior. So, with the agreement of
the language team, I'm removing it when sound-flow-analysis is
enabled.
Fixes https://github.com/dart-lang/language/issues/4380.
Bug: https://github.com/dart-lang/language/issues/4380
Change-Id: Ic1ca80a61e21482e659afa8796b08fce707db3c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429227
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Use "out.aotsnapshot" as the name for all non-assembled snapshots and
names with the appropriate shared object extension for the host OS for
assembled snapshots.
This ensures the test checks for .dll extensions added in
https://dart-review.googlesource.com/c/sdk/+/428200 only trigger
for assembled snapshots as expected, and not for other formats
(e.g., Windows trybots using sanitizers, which still use direct
to ELF snapshots).
Also fixes incorrect line numbers in dwarf_stack_trace_test.dart.
TEST=vm/dart/build_id_test
standalone/dwarf_stack_trace_test
Cq-Include-Trybots: luci.dart.try:vm-asan-win-release-x64-try,vm-linux-release-x64-try,vm-mac-release-arm64-try
Bug: https://github.com/dart-lang/sdk/issues/60846
Change-Id: Ife06613d86874d76adeb99dcbc50fc3723aae584
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432660
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Adds a Mach-O loader, similar to the existing ELF loader, that
can be used on platforms that do not support loading Mach-O dynamic
libraries via dlopen().
Other changes:
* Renames the --force-load-elf-from-memory command line argument
to --force-load-from-memory.
* Use CPU_TYPE_ANY and CPU_SUBTYPE_ANY for architectures that do
not have specific constants in <mach/machine.h> (e.g., RISCV),
as the snapshot header check after loading also catches architecture
mismatches.
* Emit the unwinding information at the end of the text segment
for Windows Mach-O snapshots as is done for ELF ones.
TEST=vm/dart/unobfuscated_static_symbols_test
vm/dart/use_dwarf_stack_traces_flag_test
Issue: https://github.com/dart-lang/sdk/issues/60307
Change-Id: I34a2a334f47d18d5c4f4a712956e71fd0ac94024
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-debug-x64-try,vm-mac-release-arm64-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-dwarf-linux-product-x64-try,vm-linux-debug-x64-try,vm-mac-debug-arm64-try,vm-fuchsia-release-x64-try,vm-fuchsia-release-arm64-try,vm-linux-debug-ia32-try,vm-aot-linux-debug-simarm_x64-try,vm-aot-linux-debug-simriscv32-try,vm-aot-linux-debug-simriscv64-try,vm-aot-linux-release-simarm_x64-try,vm-gcc-linux-try,vm-ubsan-linux-release-arm64-try,vm-aot-win-release-arm64-try,vm-aot-win-release-x64-try,vm-win-release-x64-try,vm-win-release-arm64-try,vm-aot-win-debug-arm64-try,vm-win-debug-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430100
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
A tricky part of the implementation of flow analysis is the handling
of try/finally statements. Although promotions are tracked separately
in the `try` and `finally` blocks, promotions from both blocks need to
be merged together at the conclusion of the finally block. This
creates an ambiguity, because each type in a promotion chain is
required to be a subtype of the previous, and hence multiple
promotions of the same variable are inherently ordered. The ambiguity
is: when the promotions from the `try` and `finally` block are merged,
which promotions should be applied first?
In discussion with the language team, we've decided that the
promotions from the `try` block should be applied first, because that
matches the order of code execution. This change makes the behavior of
flow analysis more uniform, which should make it easier to reason
about and maintain.
In practice, the difference in behavior is quite subtle, and I don't
expect users to notice. However, to be on the safe side, the change in
behavior is conditioned on the `sound-flow-analysis` flag, so it will
only take effect when the user deliberately upgrades to language
version 3.9, and it will not affect already-published packages.
A test in google3 showed that no internal code would be broken by
force-enabling this change.
Fixes https://github.com/dart-lang/language/issues/4382.
Change-Id: I0e9f6db808a964e0b4325d3020654a9f2be273a2
Bug: https://github.com/dart-lang/language/issues/4382
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432001
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, flow analysis had the rule that type promotion only
occurred when the type being tested was a subtype of the previously
promoted type (or the declared type, if there was no previous
promotion). This led to counterintuitive behaviors when the type being
tested and the previously promoted type were mutual subtypes (see
https://github.com/dart-lang/language/issues/4368).
With this change, the rule is updated so that type promotion only
occurs when the type being tested is a subtype of the previously
promoted type _and_ the previously promoted type is _not_ a subtype of
the type being tested. The user-visible difference is that promotion
to a mutual subtype no longer occurs.
This change makes flow analysis easier to reason about, and improves
its behavior in corner cases, but I believe it will have minimal
impact on real-world code. But to reduce the risk to existing code,
the change only takes effect when the `sound-flow-analysis` language
feature is enabled.
Fixes https://github.com/dart-lang/language/issues/4368.
Bug: https://github.com/dart-lang/language/issues/4368
Change-Id: I30dab017e043e75603d618df721c8a2683667cd5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429200
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Having forwarding tables on the Thread allows for those tables to be used in dart mutator thread running in IsolateGroup-shared context. On 32-bit platforms(arm) the forwarding tables are used during [SendPort.send] message verification.
Fixes https://github.com/dart-lang/sdk/issues/60817
TEST=isolate_group_shared_send_test
Change-Id: I58b33c14026584330b594776e812fe1d48bc2fd5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431942
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Use a combination of gen_snapshot's new ability to generate dylibs directly and the copy of llvm in buildtools to avoid using XCode, which is not available in shards.
Add definitions for debug builders now that they can complete without timing out.
Cq-Include-Trybots: luci.dart.try:vm-aot-mac-product-arm64-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try
Change-Id: I79924128f11aafab4cd74ea6e9ab5848c64557da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431700
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
By tracking `isCallOnInterceptor`, we avoid the need for class context
information in the `sourceElement` to compute the value. `sourceElement`
is now purely advisory to the choice of local names in codegen, and
can't be the wrong kind of element as in issue #60793.
Bug: #60793
Change-Id: I8bb68b6bf864a3a6f9f2beb40f68a6254431d49a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432003
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
This CL fixes co19/LanguageFeatures/Static-access-shorthand
/semantics_A05_t01.dart.
While working on this, I realized the static type was wrong and we weren't doing any inference for the constructor references so I updated the logic.
Unit tests passing, language test expectations are actually better than before and that particular co19 test passing.
Bug: https://github.com/dart-lang/sdk/issues/59835
Change-Id: I7437079c33640f53f48a4445890fadfebc9ec158
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430561
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
We add the `dart.tool.dart2wasm.minify` environment define (analogous to
how dart2js exposes `dart.tool.dart2js.minify`).
We make `package:expect/variations.dart` then expose to tests what
guarantees they can assume, namely
* `readableTypeStrings`
* `preciseErrorsWithDetails`
Change-Id: I43da09ed924ca9137721f4d70b7a494e01bf36e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430680
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
With b32e5e5a91 under --experimental_shared_data flag, `LoadStaticField` calls initializer stub to confirm presence of isolate when accessing non-shared static fields. This breaks the role that `calls_initializer` attribute/parameter used to play where it was specifically describing neccessity to call initializer, which is important in how `LoadStaticField` instruction is used in static field setters - it should not attempt to call initialzer.
This CL fixes the problem by renaming current `calls_initializer` `LoadStaticFieldInstr` attribute to `does_slow_checks`, and "adding" separate `calls_initializer` parameter to the instruction to signify specifically whether initializer has to be called.
TEST=ci
Change-Id: Ib81424864c98d889fb6dbb9dd15dac9a39c530f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429062
Reviewed-by: Slava Egorov <vegorov@google.com>
`needsCapture` will ensure that any variables used within an async scope get included in the 'asyncScope' object that's created for that scope.
The variables used to lower Dart late variables in particular get emitted separately. But they can still be used across async scopes so they need the special capture logic as well.
Bug: https://github.com/dart-lang/sdk/issues/60748
Change-Id: I2486fce41f88f186fd799029c2cc59635f7ad8f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429780
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
To make sure Dart values with typed data types like `Uint8List`, `List`,
`String` etc. hold the right type of JS values, check types of JS
references in boxing functions that return Dart typed data types.
To reflect what the functions actually do, and for consistency with
other functions, boxing factory names are changed from `fromJSArray` to
`fromRef`.
New boxing functions `fromRefUnchecked` added for the call sites that
already know the reference type to be the right type, for example in
`dartifyRaw`.
These unchecked functions will also be used in CL 424021 where we
replace some `dartifyRaw` calls with more precise "dartify" functions
that only converts when the type is right. (`dartifyRaw` always boxes
the argument regardless of the type)
Issue: https://github.com/dart-lang/sdk/issues/60357
Change-Id: Icdfb49b9b235d35af2af0c4be51b295ee68d99fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429362
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
When we create a `Selector` we compute various information
based on all members belonging to that selector. Before this
CL this was split up: Some things like `ParameterInfo` was
calculated&updated while discovering members, others was
calculated after all members were discovered.
We now make all fields whose value depends on knowing all
members `late final` and initialize those fields after
having found all members of a selector.
When we compute the `ParameterInfo` of the selector we take
special care:
If there's non-abstract implementations and the selector is
not overridable by dynamic modules then we create the
`ParameterInfo` by looking only at the non-abstract members
=> This increases precision as we ignore the types and
default values of optional parameters for abstract members
If there's no implementations of the selector it may still be
referred to by instance invocation AST nodes (which are
unreachable). The current code generator still needs a
`Selector.signature` in order to evaluate arguments for such
nodes.
=> We calculate `ParameterInfo` based on the abstract member
and use `defaultSentinel` for optional parameters.
If a selector can have implementations in dynamic modules
then we cannot determine whether all implementations have
the same default value of optional parameters.
=> We calculate `ParameterInfo` using `defaultSentinel`
value for all optional parameters. Ensuring the caller
doesn't pass them but the callee will default to it's
default value if it wasn't passed by caller.
See added test case for when we (before this CL) may
use unreachable members in the param info / signature
calculation and how that could lead to a compiler bug
(before this CL) due to a missing
`VariableDeclaration.initializer`
TEST=web/wasm/unreachable_selector_implementation_test
Change-Id: I3628177f8e93c5d24ff0eb0ff8fee6121a4a08d1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428541
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
When running the test from Powershell Platform.executable is absolute path, rather than relative when invoked from Command shell. That breaks the test when running from Powershell.
This change fixes the test to always use Platform.resolvedExecutable.
```
PS C:\src\d\sdk> out\DebugX64\dart.exe tests\ffi\native_assets\infer_native_assets_yaml_dart_kernel_snapshot_test.dart
invoke helper with --package=...
File copied to file:///C:/Users/aam/AppData/Local/Temp/tests_ffi_native_assets_b0de5819/infer_native_assets_yaml_dart_kernel_snapshot_helper.dart.
Unhandled exception:
Unsupported operation: Cannot extract a file path from a c URI
<asynchronous suspension>
<asynchronous suspension>
<asynchronous suspension>
<asynchronous suspension>
<asynchronous suspension>
PS C:\src\d\sdk>
```
after
```
PS C:\src\d\sdk> out\DebugX64\dart.exe tests\ffi\native_assets\infer_native_assets_yaml_dart_kernel_snapshot_test.dart
invoke helper with --package=...
File copied to file:///C:/Users/aam/AppData/Local/Temp/tests_ffi_native_assets_3dfd90fc/infer_native_assets_yaml_dart_kernel_snapshot_helper.dart.
File native_assets.yaml written to file:///C:/Users/aam/AppData/Local/Temp/tests_ffi_native_assets_3dfd90fc/.dart_tool/native_assets.yaml.
dill file created: file:///C:/Users/aam/AppData/Local/Temp/tests_ffi_native_assets_3dfd90fc/infer_native_assets_yaml_dart_kernel_snapshot_helper.dart.dill
invoke helper with --package=... done
invoke helper in working dir
File copied to file:///C:/Users/aam/AppData/Local/Temp/tests_ffi_native_assets_c7f57eac/infer_native_assets_yaml_dart_kernel_snapshot_helper.dart.
File native_assets.yaml written to file:///C:/Users/aam/AppData/Local/Temp/tests_ffi_native_assets_c7f57eac/.dart_tool/native_assets.yaml.
dill file created: infer_native_assets_yaml_dart_kernel_snapshot_helper.dart.dill
invoke helper in working dir done
```
TEST=ci, manually from powershell.
Change-Id: Ie0d6cdb2ecdd69bb44a8ea820ce71405344c1307
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429080
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
This CL introduces variance-dependent treatment of the `Handle` native
type when converting native types to Dart types. Since `Handle` can
represent any object, it should match any type. To achive that in
cases when `Handle` appears as the subtype in the subtype checks, it's
converted to `Never` in covariant positions and to `Object?` in
covariant ones.
TEST=existing
Issue https://github.com/dart-lang/sdk/issues/49518
Change-Id: Ie16a210491ada80d21f4d0f1c0fa3b3804881ede
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/426880
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
The way this is accomplished is that in
`_FlowAnalysisImpl.nullAwareAccess_rightBegin`, any expression
reference associated with the target of the null-aware access is
restored, and the corresponding SSA node is associated with the guard
variable (if any). These changes ensure that if the null-aware access
is a property get, the subsequent call to `propertyGet` will pick up
the appropriate SSA node, so it will be able to locate the promotion
key for the property.
This functionality is only enabled when the language feature
`sound-flow-analysis` is enabled.
To prevent test regressions, a few related changes need to be made at
the same time:
- `_FlowAnalysisImpl.nullAwareAccess_end` is changed so that it clears
any expression info or expression reference that was associated with
the null-aware access expression. This prevents flow analysis
information from being erroneously propagated out of a null-aware
expression, which would have led to assertion failures when
analyzing null-aware expressions inside of conditional
expressions. This wasn't previously a problem because the expression
reference used to be consumed by
`_FlowAnalysisImpl.nullAwareAccess_rightBegin`, preventing further
expression references and expression infos from being recorded
further along in the null-aware access.
- The test framework in `mini_ast.dart` is fixed so that `!` is
considered to participate in null shorting. This was a bug in the
test framework that wasn't previously caught because it happened not
to produce any test failures.
- The analyzer's method `PostfixExpressionResolver._resolveNullCheck`
is changed so that it calls `nonNullAssert_end` before terminating
null-aware access. Previously, the order was swapped, causing
`nullAwareAccess_end` to be called before `nonNullAssert_end` when
analyzing expressions like `a?.b!`. This used to be benign, but now
that non-cascaded field accesses participate in field promotion,
flow analysis needs the methods to be called in the correct order.
Fixes https://github.com/dart-lang/language/issues/4344.
Bug: https://github.com/dart-lang/language/issues/4344
Change-Id: I523be1b4be1af3f68654a745187a546728c878fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427820
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
`_potentiallyAssertNotNull` would insert null checks to catch issues
from mixing libraries sound and unsound null safety. The null checks
are now always optimized away so we might as well never insert them.
Bug: #60327
Change-Id: I092a4fb336e46bf33b9b3cd9867dd7b6d8f9c65e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427569
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Update isolate_group_shared_callback_test to use that and also use flag to print exceptions.
TEST=ci
CoreLibraryReviewExempt: only internal library is affected
Change-Id: Ia53ca7a6dc847b551229ccf00bbbfe302a260fcb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427680
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Alexander Aprelev