This makes the flow analysis unit tests more similar to the behavior
of the analyzer and CFE, in that the types of various properties are a
property of the program being analyzed, not of the individual property
gets themselves.
Change-Id: I6ea164665093ee285325a64e80f3f52d7a63cf74
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193836
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Add a SsaFinalizeInterceptors phase that does optimizations with the
interceptor calling convention.
This puts the the caller and callee sides of the dummy explicit
receiver optimization in the same phase.
Change-Id: I07fe0483c2658c3744b76a235edb24720d7ea60f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193140
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
This changes the span reported from the _receiver_ to
the _use_ (method name, property name, operator token).
I think this change is overall an improvement.
Specifically, its a great improvement for cmdline
output, where the receiver and the "use" are on
different lines.
One possibly weird change is that if the operator is `[]`,
then I only highlight the `[` character. I don't know if
there is a better place, and I think this is fine.
Fixes https://github.com/dart-lang/sdk/issues/43708
Change-Id: Ie66ddf04b4904a367575193106385dd63ee39985
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/188680
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Before value is stored into Float32List, it is converted to 32-bit
float using DoubleToFloat instruction. If allocation sinking
eliminated the allocation of Float32List but we need to deoptimize,
the list is materialized and elements are filled. In such case,
we shouldn't perform double->float conversion as it already happened.
This change also updates the assertion in DoubleToFloatInstr::Canonicalize
which verifies that DoubleToFloat instruction can be used only
in certain cases.
TEST=tests/language/vm/allocation_sinking_arrays_test.dart
Fixes https://github.com/dart-lang/sdk/issues/45547
Change-Id: I9a1bd28a9fc09bccad6aa3c91a7880abd002f7c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193831
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Dart code did not expect OSError as a return value from Socket_GetPort.
This CL ensures that Dart code handles OSError in addition to int gracefully as a result of Socket_GetPort call.
Fixes https://github.com/dart-lang/sdk/issues/45116
TEST=run dart ci socket tests on mac with transparent proxy running
Change-Id: I198d99107729ccefecd9a16b71474ccdbfc0039b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193221
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
It can sometimes happen that multiple error messages point to equal
context messages. To prevent the static error test runner from
getting them mixed up, we need to use identity maps to track the
mapping from error message to context number.
Change-Id: I6d03484a37519d5db1f92750273daf898cb4381a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193527
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
OSThread::GetCurrentThreadId() is used in many places throughout
the vm, particularly in facilities that are used heavily, such as
SafepointRwLock. The high frequency of invocations means that the
runtime overhead of getting the current thread id has a significant
impact on the overall performance of the vm.
The current Fuchsia implemention of OSThread::GetCurrentThreadId()
makes a syscall to get the koid of the current thread's handle,
resulting in hundreds of nanoseconds of unnecessary overhead per
invocation.
This patch changes to using the thread's handle as the id, which is
guaranteed to be unique for the lifetime of the thread, unless it
is closed prematurely (nothing in the vm does this). This approach
is similar to what MUSL libc (the libc used by Fuchsia) does for
the same purpose and has significant mileage.
Bug: b/182183059
TEST=existing ci test suite; manually deployed into Fuchsia build.
Change-Id: I274a793a823a717c8dd206b396001c6acb897b9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193643
Reviewed-by: Chase Latta <chaselatta@google.com>
Commit-Queue: Chase Latta <chaselatta@google.com>
This change extends EqualityCompare IL instruction to handle case
when operands are nullable ints.
Unlike CheckedSmiComparison, EqualityCompare performs comparison
without making a dynamic call on a slow path. Dynamic call in
CheckedSmiComparison is a problem because it is not present in
the original program and not properly tracked in TFA and precompiler,
so precompiler is not able to drop Code objects (needed for
dynamic calls) reliably.
This change removes the remaining case when CheckedSmiComparison
instruction was used. The cleanup will follow in a separate CL.
TEST=ci
Issue: https://github.com/dart-lang/sdk/issues/32166
Issue: https://github.com/dart-lang/sdk/issues/44852
Change-Id: I8114a2616becf632462d4cb3bfc255691f24e1ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193447
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Previously, if the migration tool encountered a Future expression with
a bad type (e.g. a Future<String?> where a Future<String> was needed),
it would "fix" the problem by introducing a cast. That is nearly
always the wrong thing to do; what we want to do is null check the
value that the future *completes* with.
This CL changes the migration tool so that it fixes this case by
appending `.then((value) => value!)` to the future expression.
Fixes#45472.
Bug: https://github.com/dart-lang/sdk/issues/45472
Change-Id: I7a35b54f673936e2e4b0f8f3a077ba8bf684b4eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193700
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Elimination of redundant type cast 'x as Function' where x is
a function type (such as 'void Function(int)') is not correct because
it changes semantics of a function call if such expression is
used as a receiver.
"Function" static type of receiver allows arbitrary function calls,
while known function type of the receiver means the call doesn't
need to check parameter types. Static type of receiver is currently
not stored in kernel AST but calculated from the receiver node,
so replacing 'x as Function' with 'x' changes static type of
the receiver from "Function" to function type.
TEST=tests/language/regress/regress45428_test.dart
Fixes https://github.com/dart-lang/sdk/issues/45428
Change-Id: If7148450526703daa63a442adf67a9e7a2dcea54
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193524
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The ID tests for the "why not promoted" feature had some minor
unintentional errors in them. This CL fixes them:
- The constructor tests in
argument_type_not_assignable_nullability_error.dart tried to return
null from functions whose return type didn't allow it.
- The compoundAssignmentRhs test in
argument_type_not_assignable_nullability_error.dart tried to add an
`int` to an `int?`. The CFE considers this to be an error, but also
reports a follow-on error because it thinks the type of the
resulting expression is `num` (which is not assignable back to
`int`). To avoid the follow-on error, we use `num` for the type of
the variable to which compound assignment is being applied.
- The forElementInMap test in
for_in_loop_type_not_iterable_nullability_error.dart wasn't a proper
map (it contained two `null` elements, rather than a single map
entry `null: null`, which was what was intended).
There were also several tests for which we *don't* expect "why not
promoted" information; I added comments explaining why.
Change-Id: I91ddb88cb0f25f9b209df3eeb75d57d8270f877b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193561
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Alexander Aprelev