I have tried several attempts to make the test continue to work,
including:
* Running JIT pipeline with the special TD AOT optimization pass
* Running AOT pipeline, clear deopt ids and run in JIT
* Change only parts of compiler backend
None of the approaches are working really well, so we'll just not run
the code.
The vm/cc/IRTest_TypedDataAOT_FunctionalGetSet continues to check the
generated IR graph.
Closes https://github.com/dart-lang/sdk/issues/41148
Change-Id: I81c3f7900443eb5a5ed7b9641185b9b9d5c4debb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141245
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Current implementation of late fields represents all tests for sentinel
value as an explicit LoadField and comparison. As a result, IL with
inlined late final field getter may look like
v23 <- LoadField(v2 . lateFinalField {final}) T{int?}
Branch if StrictCompare:4(===, v23, v16) goto (7, 8)
B7[target]:8
v28 <- StaticCall:14( init:lateFinalField<0> v2) T{int?}
v30 <- LoadField(v2 . lateFinalField {final}) T{int?}
Branch if StrictCompare:16(===, v30, v16) goto (10, 11)
B10[target]:20
goto:26 B12
B11[target]:22
StaticCall:28( _throwNew@0150898<0> v33)
goto:30 B12
B12[join]:24 pred(B10, B11)
StoreInstanceField(v2 . lateFinalField = v28)
goto:32 B9
B8[target]:10
goto:34 B9
B9[join]:12 pred(B8, B12) {
The second LoadField and comparison is needed to verify that initializer
hasn't assigned field value before (in a recursive invocation).
The second LoadField is dominated by the first LoadField, so CSE
replaces v30 with v23 if late final fields are treated as immutable
like all other final instance fields. After that comparison is removed
and check for the repetitive assignment is fully eliminated.
So, the fact that value of final late field is mutated should be
exposed in the IL and slots corresponding to late final fields
should not be marked as immutable.
The following tests began passing:
dartkp-strong-linux-release-x64:language/nnbd/syntax/late_modifier_edge_cases_test was fixed (RuntimeError -> Pass)
dartkp-weak-asserts-linux-release-x64:language/nnbd/syntax/late_modifier_edge_cases_test was fixed (RuntimeError -> Pass)
Change-Id: I4191a5cb4c1a583c8b8ad81d1f42f4cb4821e51a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141821
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
FFI trampolines are stored in the global object pool and not
reachable either via class or via the closure functions in the
object store.
Fixes https://github.com/dart-lang/sdk/issues/41261
Bug: https://github.com/dart-lang/sdk/issues/41052
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-linux-release-simarm_x64-try,vm-kernel-precomp-mac-release-simarm64-try,vm-kernel-precomp-win-release-x64-try
Change-Id: I3e1551dba80a2fd418946d7449467317463c2c61
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141882
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The following tests began passing:
dartkp-strong-linux-release-x64:language/nnbd/is_type_test/null_is_type_in_null_safe_lib_test was fixed (RuntimeError -> Pass)
dartkp-weak-asserts-linux-release-x64:language/nnbd/is_type_test/null_is_type_in_null_safe_lib_test was fixed (RuntimeError -> Pass)
Change-Id: I0601e9b43c92764ca62f1993df3443a6cc0f93bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141700
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
In particular, don't serialize a function if its code is used by the
dispatch table, but there's no need for the function object itself
at runtime like dynamic lookup or dynamic invocation forwarders.
However, just because the owning function is not needed at runtime,
it may be used during serialization for things like assembly label
creation. Thus, instead of just clearing out the Code's owner field,
we add a new WeakSerializationReference (WSR) object whose target is
the original contents of the owner field. The WSR allows the
serializer to access the original owner, but also signals to the
serializer that the target should not be serialized in AOT snapshots
unless there are additional strong (non-WSR) references.
If no strong references are found, then the references to the WSR
in the snapshot are replaced with a reference to a WSR that only
contains the class ID of the original target. The serializer creates
only one WSR per class ID.
If strong references are found, then the target is still serialized.
In this case, the WSR is dropped entirely and any reference to it is
replaced with a direct reference to the serialized target. Thus, WSRs
only exist in the precompiled runtime for targets with no strong
references.
Changes on the Flutter gallery in release mode:
arm7: total size -1.10%, isolate size -6.08%
arm8: total size -1.16%, isolate size -6.09%
Bug: https://github.com/dart-lang/sdk/issues/41052
Change-Id: I5b435ca71ef85f50fe3484789087471a91aa4fe2
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-linux-release-simarm_x64-try,vm-kernel-precomp-mac-release-simarm64-try,vm-kernel-precomp-win-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/137104
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Only mark static fields with initializers as late in opted-in
libraries (static fields without initializers should be still
pre-initialized with null and not sentinel).
Change-Id: I1371757c383ca53cc6cc798a31395f039b8719d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/141341
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Nullability of left hand side in type test was checked too early, i.e. before
handling FutureOr on the right hand side.
The following tests began passing (in strong mode):
standalone/io/addlatexhash_test was fixed (RuntimeError -> Pass)
standalone/io/file_output_stream_test was fixed (RuntimeError -> Pass)
standalone/io/file_stream_test was fixed (RuntimeError -> Pass)
standalone/io/file_system_async_links_test was fixed (RuntimeError -> Pass)
standalone/io/file_system_links_test was fixed (RuntimeError -> Pass)
standalone/io/file_write_only_test was fixed (RuntimeError -> Pass)
standalone/io/pipe_server_test/0 was fixed (RuntimeError -> Pass)
standalone/io/pipe_server_test/1 was fixed (RuntimeError -> Pass)
standalone/io/pipe_server_test/2 was fixed (RuntimeError -> Pass)
standalone/io/pipe_server_test/3 was fixed (RuntimeError -> Pass)
standalone/io/pipe_server_test/4 was fixed (RuntimeError -> Pass)
standalone/io/pipe_server_test/5 was fixed (RuntimeError -> Pass)
standalone/io/stream_pipe_test/0 was fixed (RuntimeError -> Pass)
standalone/io/stream_pipe_test/1 was fixed (RuntimeError -> Pass)
standalone/io/stream_pipe_test/2 was fixed (RuntimeError -> Pass)
standalone/io/stream_pipe_test/3 was fixed (RuntimeError -> Pass)
Change-Id: I855328f101382cf5f1af9119b396aa9d0cb14e40
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140776
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Liam Appelbe <liama@google.com>
Also, tests/corelib/string_operations_with_null_test.dart is fixed for
strong mode: in strong mode TypeError is thrown when null is casted
to a non-nullable type; in weak mode null is silently passed and
ArgumentError or NoSuchMethodError is thrown.
Change-Id: I566a80293ffb03752cc3409e1b79491f0aff6888
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140779
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
According to the NNBD feature specification, "a toplevel or static
variable with an initializer is evaluated as if it was marked late".
This change actually marks all static fields in opted-in libraries
as late, in order to make sure that the rest of the VM handles
such fields uniformly as late.
Without this change implicit getters for such fields were generated
as late, but type propagation didn't treat these fields as nullable,
so field initialization checks were removed if field has a non-nullable
type.
Change-Id: I95bc096fb1d304b112369428dbb29d346964383f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140767
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Liam Appelbe <liama@google.com>
In bare instructions mode, we do not have a per-Code object pool,
but rather a global shared object pool. When generating instructions
that access the object pool, we use the index in the (eventually
created) global object pool.
Recently, when the V8 snapshot profile writer is active, we began
attaching an per-Code object pool so that each object in the global
object pool can be attributed to the Code objects that caused its
inclusion. This pool only has those objects attributable to this
Code object, and not all objects in the global pool up to the point
of compiling the Code object.
However, the disassembler currently only looks at whether the current
Code object has an object pool when decoding object pool accesses.
This was safe when there were no per-Code object pools in bare
instruction mode, but since the change described above, it attempts
to access the object in the Code-local pool at the same index as the
global pool and crashes.
This change fixes the disassembler so that we only try to decode the
object being accessed in the object pool when in non-bare instructions
mode.
Fixes https://github.com/dart-lang/sdk/issues/41149
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-release-simarm_x64-try,vm-kernel-precomp-mac-release-simarm64-try,vm-kernel-precomp-win-release-x64-try
Change-Id: I96fd61d05c657a5ee1d86565cc39c83ebee587f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140603
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Bionic implementation of setjmp mangles[1] stack pointer - which means
it is unsafe to handle signals on the thread stack (see b/152210274).
Thread interrupter is constantly sending SIGPROF to the Dart thread -
which means with a small probability it might hit the case when we are
inside setjmp. If SP is mangled it might point to random writable memory
or to non-writable region. In the first case we will get a very obscure
memory corruption, and in the second case kernel would send us SIGSEGV
because it fails to deliver original signal.
This bug is the source of the numerous mysterious crashes reported for Flutter,
looking like this:
F/libc (11547): Fatal signal 11 (SIGSEGV), code 128, fault addr 0x0 in tid 11572 (1.ui), pid 11547 (ectivity_change)
...
signal 11 (SIGSEGV), code 128 (SI_KERNEL), fault addr 0x0
...
backtrace:
#00 pc 00018abc /system/lib/libc.so (sigsetjmp+120)
Note the following key points: SIGSEGV has code SI_KERNEL (meaning it
was triggered by kernel - rather than by a hardware fault) and the first
and only frame is inside sigsetjmp (unwinding is obviously also broken
because SP is mangled).
Fixes https://github.com/flutter/flutter/issues/27077
[1] https://android.googlesource.com/platform/bionic/+/refs/heads/master/libc/arch-x86/bionic/setjmp.S#132
Change-Id: I91afa42dbf6575db0cce8e223368b857a49b39b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140643
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
If lookup succeeds, then the DWARF stack frame uses the symbol
name and offset instead of the dynamic library name. The
native_stack_traces package (once updated) can translate these
stack frames into symbolic stack frames even if given a partial
stack trace without the header.
Also, consistently use uword instead of a mix of uintptr_t and uword.
Change-Id: Ida9ba4726a306fb77b141cb9c6ad635a12a320ec
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-release-simarm_x64-try,vm-kernel-precomp-mac-release-simarm64-try,vm-kernel-precomp-win-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140282
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Dev and beta version strings will look very look very similar, so adding
the channel name will make it easy for users to see if they are on be,
dev, beta, or stable. This will change both the output of
`dart --version` as well as the value of `Platform.version`.
This also removes the Flutter stable release version hack.
Fixes https://github.com/dart-lang/sdk/issues/40993
Change-Id: Iceb8e84a9cf4d0bfb7659669878e42d0a59febc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140287
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
I missed an edge case in the subtyping rule. If the this function
has a required param, and the other function is entirely missing
that param, then we would mistakenly call that a valid subtype.
language/nnbd/required_named_parameters/required_named_args_strong_test
found the bug. This test is now passing in strong mode.
Bug: https://github.com/dart-lang/sdk/issues/40968
Change-Id: Ica13bcf4d287e13050f81652e07dcc40c155a801
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140143
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
This fixes some mirrors failures in NNBD legacy mode, since the CFE is
inserting more synthetic functions now, to handle interfacing between
libraries with different NNBD status.
Change-Id: Iad5cb2548ef118f842bf2eadf249d4dca9f38fa7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139740
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
CFE does not always normalize FutureOr<T> eagerly, e.g. it does not normalize
FutureOr<Null> parsed in the source. However, it normalizes inference or
instantiation results.
For performance reasons, the VM chooses to do it eagerly, i.e. it must also
normalize unnormalized types from a kernel file.
Change-Id: I5798333ba3c58c5b2851045ef32c345d94f58268
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139955
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
Note that the remaining failure on line 28 of test
language/nnbd/type_equality/futureOr_normalization_legacy_test
is due to the CFE failing to normalize at compile time.
Change-Id: I8e982830f59cfa5cdf45314aa7a34026975ba952
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139863
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
Hitting the assertion from the issue (see below) is innocent: It
informs us that we should avoid speculating operands to be Smis if we
actually know for sure the receiver cannot be a Smi (based on interface
target).
This particular case was hit on an instance call `a ^ b` where the interface
type tells us it is `boo.^` - so we shouldn't insert CheckedSmiOp.
There might be more cases where we insert CheckedSmiOp/CheckedSmiComparison
instructions where we shouldn't (because interface target tells us
receiver cannot be a Smi).
-> In debug mode we'll hit this assertion, so if the fuzzer finds more such
cases, we should fix them one-by-one.
Fixes https://github.com/dart-lang/sdk/issues/40937
Change-Id: I55624f77b9edeece4d1334f1629ce5514cf3784a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/139812
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Alexander Markov