In AOT the SendPort.{Send,Receive}.BinaryTree.* are really fast, because
the tree shaker will remove the fields, which will make us actually not
construct a tree at all but only one root node without fields.
TEST=Changes benchmark to work as intended
Change-Id: Idbcb1e15613b1fd071591be40c4ffd9eadc86ce5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207121
Auto-Submit: Martin Kustermann <kustermann@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
When creating a binding socket with `shared: true` there will be one
underlying [OSSocket] used. Any following bind on the same address with
`shared: true` will re-use that [OSSocket].
The code that was searching for existing sockets is correct, but the
code that increments the refcount, ... was incorrectly using the start
of the linked list instead of the found existing socket instance.
Fixes https://github.com/dart-lang/sdk/issues/46634
TEST=standalone{,_2}/io/unix_socket_regress_46634_test
Change-Id: I3ce1bdc98ecd4b5311f826ab2597a62fe048be09
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207083
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Tests static extension methods on JavaScriptObject work as
expected, as well as making sure it works with package:js. Once
extension types are added, these tests need to be changed to use
those instead.
Change-Id: I9504c8a3a8e466c680b221e259d93c1df5474218
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/199601
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Closures created via Closure::New() set the delayed type arguments to
the null type argument vector for non-generic closure functions and to
the empty type argument vector for generic closure functions. However,
closures created via the method extractor stub would always have the
empty type argument vector for delayed type arguments. Make the two
consistent by creating two method extractor stubs, one for generic
extracted methods and one for non-generic ones.
With this change, Closure::IsGeneric simply compares the delayed type
arguments against the empty type argument vector. This change also makes
method extraction for non-generic functions slightly faster, since the
delayed type arguments field is not changed post-allocation.
The old version of Closure::IsGeneric was the only use of
Closure::NumTypeParameters, so remove the latter method.
Related cleanups:
* Use similar checks for Class::IsGeneric and FunctionType::IsGeneric,
since they only have non-null type_parameters fields when generic.
For Class::IsGeneric, this avoids having to fetch the current thread
if the class declaration has been loaded.
* Refactor methods that read packed fields in FunctionType into two
methods, a static method that takes a FunctionTypePtr and an instance
method that calls the static method. Replace the methods in Function
that also directly read FunctionType packed fields with delegations to
the static methods.
* Rework Closure_equals to avoid unneeded handle allocation in certain
cases for non-equal closures.
* Replace cases that allocates a handle for the closure function only
for retrieving the signature with calls to Closure::signature().
TEST=language_2/closure/tearoff_dynamic_test
language_2/regress/regress45890_test
Cq-Include-Trybots: luci.dart.try:vm-kernel-linux-debug-x64-try,vm-kernel-linux-debug-x64c-try,vm-kernel-nnbd-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64c-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-simarm64-try,vm-kernel-nnbd-linux-release-simarm-try,vm-kernel-nnbd-linux-release-simarm64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-nnbd-linux-release-simarm64-try,vm-kernel-linux-debug-simarm64c-try,vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-nnbd-linux-debug-simarm_x64-try
Change-Id: I29c8859c3350ed7b3f1a8f71d82a4393496b7c2b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206820
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Replaces jsobject instance with JavaScriptObject as the base type of
all JS objects.
It does NOT treat the object as an instance of the class however,
so any members defined in JavaScriptObject are ignored, which is why
any existing ones are stripped from the class. It also avoids
impacting the calling convention on these types. Lastly, the CL
allows transitive subtyping between the JS type hierarchy and the
JavaScriptObject type hierarchy.
Change-Id: Iccabcd6580870cac8d2a8f24494bc41325eb17f3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/199600
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Preparation to begin migrating dev_compiler libraries to null safety.
With this change any file we remove the old language version comment
from will be opted into null safety.
Change-Id: I567d139a6c6bfa0b8f820b16e3eb87a2f49228b3
Issue: https://github.com/dart-lang/sdk/issues/46617
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206961
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
The race with field store that might be updating field guards is benign
as cloned object will be checked against updated field state later as
optimized code(that used a cloned field) gets installed.
Fixes https://github.com/dart-lang/sdk/issues/46627
TEST=iso-stress buildbot
Change-Id: I8374359f9538ecf9f38b1e1535688ce33c6886fe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207042
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This CL deletes BaseDartTypeVisitor and makes all of the visit* methods
in DartTypeVisitor abstract. This forces subclasses of DartTypeVisitor
to provide definitions for all of these methods rather than relying on
some default.
The old code led to a series of bugs with the same root cause: when a
new kind of DartType was added (and a corresponding visit* method added
to DartTypeVisitor), not all concrete implementations of the visitor
were updated to handle the new DartType. This didn't produce static
errors because DartTypeVisitor provided default no-op implementations
for visit* methods. In some cases, this was the desired behavior anyway,
but in practice, any time a new DartType is added, we want our tools to
yell at us until we've validated that it's properly handled everywhere
(even if the proper handling turns out to be "do nothing").
This CL also updates Namer.getTypeRepresentationForConstant to use a
visitor pattern.
Fixes: https://github.com/dart-lang/sdk/issues/46589
Change-Id: I451b592ae1ce4afff40de913535798a62e17b8b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206943
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
As of 1d54dab2 this is no longer true.
TEST=No code changed.
Change-Id: I0e3a8bcf565b495ddb33bb1c555834e79dea68ad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207081
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
In https://dart-review.googlesource.com/c/sdk/+/191862 we added two new
required fields to `Location`. Unfortunately this was a breaking change
because plugins using an older version of the `analyzer_plugin` produce
location objects without those fields, leading to deserialization failures.
This CL makes those fields optional in order to fix the deserialization
issue.
Unfortunately, the `analyzer_plugin` package was published after the
required fields were added. Making them optional is a breaking change
because the constructor parameters go from being positional to being
named parameters.
We also neglected to update the version number of the protocol as part
of the previous CL. Technically this is also a breaking change for clients
of the analysis server, but given that they had no way to test to see
whether these fields existed they would need to have been written as if
the fields were optional in order to reference them at all, so I think
that from a practical standpoint it isn't a breaking change. That does,
however, raise the question of whether we should increment the version
numbers as part of this CL.
Change-Id: I35fc1f8e950669a3d8dd33cee6b81890261b5c47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206942
Reviewed-by: Danny Tuppeny <danny@tuppeny.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Even though all canonical objects can be shared, they might cause
re-hashing on the receiver side due to user-defined get:hashCode
implementation.
This is why we do not consider the canonical bit (of a key in a map) when
determining whether rehashing is needed.
Though some well-known classes will have a properly behaved
get:hashCode, the most important being for kNullCid.
=> So we'll allow kNullCid, kBoolCid.
This makes receiving json data much faster due to not needing to re-hash
anymore (was done due to `null` values in the map backing store).
TEST=Existing test suite.
Change-Id: Ie6d39da7fe27ce8925644cf2c17a3944a9e936b2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207080
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
MSVC(unlike clang) seems to have a problem with such a use:
```
ninja -t msvc -e environment.x64 --
"C:\src\depot_tools\win_toolchain\vs_files\20d5f2553f\VC\Tools\MSVC\14.26.28801\bin\Hostx64\x64/cl.exe"
/nologo /showIncludes /FC
@obj/runtime/vm/libdart_vm_jit.runtime_entry.obj.rsp /c
../../runtime/vm/runtime_entry.cc
/Foobj/runtime/vm/libdart_vm_jit.runtime_entry.obj
/Fdobj/runtime/vm/libdart_vm_jit_cc.pdb
C:\src\dart-sdk\sdk\runtime\vm\runtime_entry.cc(3683): error C2121: '#':
invalid character: possibly the result of a macro expansion
C:\src\dart-sdk\sdk\runtime\vm\runtime_entry.cc(3683): error C2059:
syntax error: 'if'
C:\src\dart-sdk\sdk\runtime\vm\runtime_entry.cc(3693): error C2121: '#':
invalid character: possibly the result of a macro expansion
C:\src\dart-sdk\sdk\runtime\vm\runtime_entry.cc(3693): error C2059:
syntax error: 'if'
```
TEST=build sdk on Windows with msvc(rather than clang)
Change-Id: I520b32bf38bc7880f45d93223779f10cbde59af6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207041
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
When evaluating arguments of an unreachable call tree shaker previously
inserted a sequence of nested Let expressions:
Let tmp0 = arg0 in Let tmp1 = arg1 in ... in result
Such AST declares unnecessary local variables and may have a deep
nesting (which may potentially cause excessive stack usage and stack
overflow). This change adjusts tree shaker to use BlockExpression
with ExpressionStatements instead of nested Let nodes:
block {
arg0;
arg1;
...
} => result
TEST=existing tests
Change-Id: Ic08fd4f4a18a64f73540b6dc17decbe68e58f55d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206900
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The migration tool already correctly infers nullability or
non-nullability based on the code generated by the built_value
package. However, post-migration, code should no longer use
built_value's `@nullable` annotation, since the built_value package
gets its signal from the `?` type suffix instead.
The migration tool already has the ability to remove annotations in
certain rare circumstances; it's a relatively trivial matter to extend
it to remove `@nullable` annotations when appropriate.
Note that we don't just remove any `@nullable` annotation; we only
remove those annotations that resolve to the `nullable` constant
defined in the `built_value` package.
Fixes#43878.
Bug: https://github.com/dart-lang/sdk/issues/43878
Change-Id: I39c9b5e6fe4cd149b6d9549cd785d7b87c3185d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206940
Reviewed-by: Samuel Rawlins <srawlins@google.com>
- Tests that non-leaf calls transition generated -> native,
and that leaf calls don't.
- Tests that leaf calls with Handle argument or return type
results in a compile-time error.
- Adds note explaining why there is no ffi_2 version.
TEST=tests/ffi/ffi_native_test.dart
Cq-Include-Trybots: luci.dart.try:analyzer-linux-release-try,analyzer-nnbd-win-release-try,analyzer-analysis-server-linux-try,analyzer-win-release-try,analyzer-nnbd-mac-release-try,analyzer-nnbd-linux-release-try,analyzer-mac-release-try,flutter-analyze-try
Change-Id: I9af60e21f5122f2479c909a52249809850824692
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206788
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
We should use store-release when publishing static-const-field values
(to ensure initialalizing stores are visible) and use load-acquire when
accessing them (to please TSAN).
There's no locking required, since concurrent threads would evaluate to
the same canonical constant.
Issue https://github.com/dart-lang/sdk/issues/46628
TEST=Fixes data race reported by TSAN on iso-stress builder.
Change-Id: Ib50423705065ae491ba99b65090859db5afc9514
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207025
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Previously, when removing all metadata nodes from code such as this:
f({
@removeMe
int? i}) {}
If the node(s) being removed occupied entire lines (as they do in this
example), the logic for trying to decide whether to collapse together
empty `{}`, `[]`, or `()` would get confused by the fact that the text
being removed began at the start of the line, even though the parent
AST node (`@removeMe int? i`) didn't begin until partway through the
line; this would cause an assertion failure (or, if assertions were
disabled, an out-of-range error).
As of yet, this has never been a problem in practice, because the only
circumstance in which the migration engine removes metadata is when
adding other metadata (and thus the logic for trying to collapse
together empty `{}`, `[]` or `()` doesn't trigger). But in a future
CL I'll be adding logic that *can* remove the only metadata and
trigger this problem. So to prepare for that, this CL fixes the
out-of-range problem.
Change-Id: Ie2d050d656512a7c725752427eaaec1c087f3c82
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206941
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change makes the migration tool understand that the method
`BuiltValueNullFieldError.checkNotNull` expresses non-null intent.
Since the built_value code generator calls this method from generated
built_value constructors, this is sufficient to ensure that built
value getters that lack the `@nullable` annotation will be treated by
the migration tool as non-nullable.
Bug: https://github.com/dart-lang/sdk/issues/43878
Change-Id: I37a9ce584a10d2a1bb27da92f3f664632547f6ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206881
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Previously, when the migration tool encountered code like this:
class C {
int i;
C(this.i) {
assert(i != null);
}
}
the assertion would not confer non-null intent on the `i` parameter of
the `C` constructor, because the `i` referred to in the assert
statement is technically the `i` field, not the `i` parameter (and we
do not propagate non-null intent through fields).
With this CL, the migration tool treats field references in
constructors to refer to field formal parameters when possible; even
though this technically does not exactly conform to Dart semantics, it
captures user intent far better; the only cases where this would
produce an incorrect result are when the field is reassigned and then
used in the constructor; such cases are quite rare and should be easy
for the user to compensate for using migration hints when necessary.
Change-Id: I4c624dab051e62fa29f103ad08ce2ce9c5137663
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206880
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
On Android native libraries can be mapped directly from an APK
they are stored uncompressed in it. In such situations the name
of the mapping no longer provides enough information for libunwindstack
to find the original ELF file and instead it has to rely on heuristics
to locate program header table. These heuristics currently assume that
program header table will be located in the RO mapping which precedes
RX mapping. This implies the following order of segments: RO (program
header, build id section if present, .rodata), RX (.text), RW (.dynamic
and .bss).
TEST=ci, manual
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-x64-try
Change-Id: I3fa4de75c5d8841a90fd4cae1ab230d02c554f94
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206620
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
When doing optimizing compilations on the mutator thread (e.g. due to
--deterministic or --no-background-compilation) we can have situations
in which one thread is starting or in the middle of optimizing a
function while another has just deoptimized it, reaching the
deoptimization counter threshold.
We just remove this assertion which doesn't hold anymore with
--enable-isolate-groups enabled.
Fixes https://github.com/dart-lang/sdk/issues/46622
TEST=Fixes flaky assertion hit in vm/dart_2/isolates/regress_46539_test
Change-Id: I9812e3c6500113b7d948f96dc4cfcee607f56d39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207023
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This should make flaky timeouts of some tests go away as well as make
the vm/dart{,_2}/isolates/dart_api_create_lightweight_isolate_test test
pass in dwarf stack traces mode.
TEST=Gets flaky/failing tests to pass.
Change-Id: Iaa1fe484b01479f80f65539d04aba3b3798cad1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207022
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The leak can happen if isolate group creation is in-progress while the
main isolate group shuts down. This will disable isolate (group)
creation. Failure to create the isolate group will lead to the leak.
The issue can be reproduced by applying the following diff
diff --git a/runtime/vm/isolate.cc b/runtime/vm/isolate.cc
index 8993e5f3855..9335b5981d8 100644
--- a/runtime/vm/isolate.cc
+++ b/runtime/vm/isolate.cc
@@ -1894,6 +1894,7 @@ Isolate* Isolate::InitIsolate(const char* name_prefix,
}
// Add to isolate list. Shutdown and delete the isolate on failure.
+ sleep(1);
if (!TryMarkIsolateReady(result)) {
result->LowLevelShutdown();
Isolate::LowLevelCleanup(result);
Fixes https://github.com/dart-lang/sdk/issues/41883
TEST=Verified this CL fixes the leak by applying the diff above.
Change-Id: Id64f6ebe88aafa589eecb7577464323a5a28cb20
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206860
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The test uses a temporary directory that gets deleted once the test
finishes. Though some calls to async methods are not await'ed, so the
directory might get removed before the async methods are completed.
We instead change the test to use synchronous methods consistently. The
regression test is still testing the `rename` method as before.
TEST=Fixes iso-stress builder failures where this issue occurs.
Change-Id: Ide3098fa67de619756417e83df056cf5d1299189
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207003
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This CL fixes AOT failures that happened after [0] landed. That code
removed lookup code for the `future_class()` in the
`ObjectStore::LazyInit*()` methods and replaced it with an assert instead.
The change was correct, since the lazy members should be initialized
on-demand - after the core, non-lazy members.
=> Though this seemed to not be the case in AOT, which hit the assert.
The reason [0] only caused failures in AOT is because in JIT the VM is
bootstrapped only from the vm_platform.dill file and as a secondary
embedder call the application.dill file is loaded.
Yet in AOT we have a combined full_application.dill which will all be
loaded during bootstrapping. That has caused the application to be
loaded before `ObjectStore::InitKnownObjects()` was invoked.
The initialization of [ObjectStore] which contains common core library
classes/functions/fields should happen before we use the kernel loader
to load user classes (since general kernel loading depends on the
[ObjectStore] being populated).
This also ensures that `ObjectStore::InitKnownObjects()` will be called
before `ObjectStore::LazyInit*()` - since they depend on the former having
run (e.g. that the non-lazy `future_class()` member of `ObjectStore`
was set).
[0] https://dart-review.googlesource.com/c/sdk/+/206782
TEST=Fixes AOT builders.
Change-Id: I0861d1a2f39effbcea08d7796742845b874a0084
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207002
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Avoids a LateInitializationError that could occur when the VM service
connection goes down during DDS startup. Done by delaying error
reporting until after DDS has completed its initial startup flow,
ensuring that all relevant state has already been initialized when we
try to cleanup.
Fixes https://github.com/flutter/flutter/issues/86361
Change-Id: I2b357bfb95c759d301ab48bce9fe1c28871d5e08
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206672
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
If two threads concurrently trigger initialization of the lazily
populated ObjectStore members, they have to coordinate.
We ensure mutual exclusion by holding a writer lock, to ensure only one
thread can perform the lazy initialization. Furthermore we use
store-release/load-acquire for those ObjectStore fields to ensure that
once an object is made available on ObjectStore all of it's initializing
stores are visible at that point.
We no longer make public setters for those fields, since they shouldn't
be used (only the getters + lazy initialization should be used)
Fixes https://github.com/dart-lang/sdk/issues/46611
TEST=Fixes TSAN races reported on iso-stres builder.
Change-Id: Icaf54bb224e74baf1bfbb4a9bfc386ebfbd52755
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206782
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
It uses eval, which is disallowed.
Change-Id: Ib125276560903846eefa3b86125350294ff5d8fd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206661
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This class wasn't really necessary; it was just a container for a few
extra methods used only by the EdgeBuilder. By moving those methods
to the EdgeBuilder and removing the _ScopedLocalSet class, we open up
the possibility of expanding the capabilities of those methods to take
advantage of other information the EdgeBuilder has access to. (I will
do this in follow-up CLs).
No functional change.
Change-Id: I7cf19b8cf81db0413f4a9e747d46fb619d5eac4e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206840
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, _ScopedLocalSet extended ScopedSet<Element?>, but this was
unnecessary; it was an artifact of the fact that the migration tool
was migrated to null safety in a conservative way. We know that all
elements of a _ScopedLocalSet are non-null elements because they all
represent actual variables declared in the user's code.
Change-Id: I4d0c86997ff3c783cee6ea84cff80363e14c3060
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206670
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This fixes an issue during signature shaking of FfiNative calls:
`type 'ConstantExpression' is not a subtype of type 'VariableGet' of 'value'`
Which is triggered by the Arguments list having type List<VariableGet>.
TEST=ffi/ffi_native_test
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-nnbd-linux-release-x64-try
Change-Id: Iafcbca8018dab091b825277ac64a51587c929ea0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206787
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Clement Skau <cskau@google.com>
Running this test under TSAN can consume 15 GB of memory alone. Running
it in parallel will make the 'iso-stress' builder OOM and the bot die
with infra failure.
TEST=Should fix BOT_DIED infra failures on "iso-stress" builder.
Change-Id: I5d6a1ab99b3c4c415d1712263a29f3c70b4942e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206786
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
All of our tests relying on filesystem operations should operate in a
randomly created temporary directory. This ensures the test will not
interact badly with other tests - running in parallel.
This particular test couldn't be run multiple times concurrently,
since it would cause races to FSE creation/deletion.
TEST=Fixes iso-stress builder issue (which runs tests repeatedly in parallel)
Change-Id: I8b2e015bf4b6a9ecdfa471eb2ec887e634c2b233
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206783
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
TTS can be generated on multiple threads at the same time and we should
therefore given them unique names by using an atomic counter.
Fixes https://github.com/dart-lang/sdk/issues/46609
TEST=Fixes one TSAN issue on iso-stress builder.
Change-Id: I4a318106a901cebe30914ac42f858cf3daced74c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206742
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
