In for instance https://dart-review.googlesource.com/c/sdk/+/193961/5
we had an instance of something good happening (a crashing-ish test
that started to pass) but where the author was told no (red bot) and
not given a path to make the bot happy (bad messaging).
Specifically tests failed and the best log one got was
```
To re-run this test, run:
dart pkg/front_end/test/unit_test_suites.dart -p pkg/front_end/test/fasta/textual_outline/general/constants/js_semantics/issue45376
```
which isn't very helpful.
If running it locally a little more information is given via stdout,
but having to do that isn't great (and the little extra information
still wasn't great).
This CL updates the messaging to - hopefully - give a path to make the
bot happy. The messaging will now - directly from the log
on the bot - be
```
FAILED: pkg/front_end/test/fasta/textual_outline/general/constants/js_semantics/issue45376: Pass
To re-run this test, run:
dart pkg/front_end/test/unit_test_suites.dart -p pkg/front_end/test/fasta/textual_outline/general/constants/js_semantics/issue45376
The test passed, but wasn't expected to. You should update the status file for this test.
There's a status entry looking something like
general/constants/js_semantics/issue45376: FormatterCrash
which should be removed.
The status file is file:///[wherever]/sdk/pkg/front_end/testcases/textual_outline.status.
```
which
a) gives the extra information previously only available via stdout when
running locally (the first line).
b) Gives an explanation as to why it failed
("The test passed, but wasn't expected to.").
c) A path to make the bot green ("You should update the status file for
this test. [...] should be removed").
Hopefully this will make it easier to deal with in the future when
something good happens.
Change-Id: I838699abce580334c956d8b4753884fd600802ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194242
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL enables tree shaking of `Struct` sub classes by simulating the
native behavior in Dart code.
We call the struct constructors in let expressions where FFI trampolines
are created which allocate these struct objects in native code. This way
TFA is instructed about the native behavior. The VM recognizes these
constructor calls as dead code and removes them.
For more info see go/dart-ffi-struct-treeshaking.
Closes: https://github.com/dart-lang/sdk/issues/38721
This CL fixes the types on the generated #fromTypedDataBase constructors.
Also, this CL also cleans up the struct naming:
* _addressOf -> _typedDataBase
* _fromPointer -> _fromTypedDataBase
* #pointer -> #typedDataBase
These cleanups are not split into a separate CL to prevent updating
the .expect files multiple times.
Finally, this CL enables running a single transformer test through:
`dart pkg/vm/test/transformations/type_flow/transformer_test.dart name`
TEST=pkg/vm/testcases/transformations/type_flow/transformer/ffi_struct_constructors.dart
TEST=tests/ffi(_2)/function_callbacks_structs_by_value_generated_test.dart
TEST=tests/ffi(_2)/function_structs_by_value_generated_test.dart
Change-Id: I418d0d73bc86b234dfe5b7b04ae726c33d2b8aeb
Cq-Include-Trybots: luci.dart.try:vm-precomp-ffi-qemu-linux-release-arm-try,vm-ffi-android-debug-arm64-try,vm-kernel-precomp-asan-linux-release-x64-try,vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,analyzer-analysis-server-linux-try,analyzer-linux-release-try,dart-sdk-linux-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-reload-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193661
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This CL changes the responsibility for doing flow analysis of the
implicit variable write in a `for-in` loop as follows: if the `for-in`
loop does not declare a variable, but it assigns to a local variable,
then the flow analysis client is responsible for calling `write` on
entry to the loop.
This in turn allows us to use a single code path to track "why not
promoted" information related to all possible local variable writes;
we no longer need as much special case logic to handle for-in loops.
To make the analyzer integration slightly cleaner, we change the
argument type of FlowAnalysis.write to Node rather than Expression, so
that the analyzer can pass in the ForEachParts object when analyzing a
for-in loop.
Bug: https://github.com/dart-lang/sdk/issues/44898
Change-Id: I24b47be8eac2e276cd291a5b2f2e4444c911138f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193837
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is clearer because:
- The use of "could not be promoted" is consistent with the other "why
not promoted" messages.
- We avoid speculating about whether the variable might be assigned a
null value; this should help avoid confusion in cases where the user
can see that assigning a null value is impossible, but promotion
still fails.
- We avoid the phrase "intervening write", which is a little too
erudite.
Bug: https://github.com/dart-lang/sdk/issues/44898
Change-Id: I0b8a2132dc99dd06769677f98e6257e9b55ad9d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193820
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@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>
Function type parameters in occurring in constants were using an offset
based on the context in which the constant first occurred. This meant
that function type parameters occurring in a generic context would have
a different offset that those occurring in a non-generic context.
The loading of .dill in ast_from_binary would read all constants outside
the context and would therefore get the indices wrong on generic
function types.
This CL changes the encoding of these type parameters to always use
a fresh context.
Closes#45415
TEST=pkg/front_end/testcases/generic_metadata/from_dill/main.dart
Change-Id: Ifdaedb4581f1e022c908fc58a58ceac3d7b0900e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193481
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Add helper on DartType to compute the `NonNull` of a type and use this
instead of `withDeclaredNullability(Nullability.nonNullable).
Includes a fix in the computation of NonNull of FutureOr.
TEST=existing
Change-Id: I3399cbf89c7d3f3e90f1315b01f40957e798a1b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193400
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
These tests show that we handle >> and >>> similarly wrt to allowing
integer operations on double constants with integer values.
https://github.com/dart-lang/sdk/issues/45438 proposes to disallow these,
but that requires a new js evaluation strategy and the issue in 45376
is therefore just a consequence of the current approach.
Change-Id: I703b57d5a6562ff1c1410858b22a96655f59dc4c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193406
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
We used to have some variables called `whyNotPromoted` and others
called `whyNotPromotedInfo`, with no obvious distinction between the
two names. Now we use `whyNotPromoted` for variables holding the map
returned by `FlowAnalysis.whyNotPromoted`, and `whyNotPromotedList`
for variables holding a list of such maps.
Bug: https://github.com/dart-lang/sdk/issues/44898
Change-Id: I3823d16ef908a833e4d4526ae1c3576c73ecf1fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193083
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Before this CL we could for instance get this result:
```
$ out/ReleaseX64/dart --enable-asserts pkg/front_end/test/fasta/weak_suite.dart -DsemiFuzz=false -DskipVm=true -- weak/general/error_recovery/issue_39058.crash
[...]
1 failed:
weak/general/error_recovery/issue_39058.crash: Pass
```
The reason is, that before it onle rewrote the expectations if there was
exactly one expectation.
`weak/general/error_recovery/issue_39058.crash` for instance (currently)
has two expecations: RuntimeError and SemiFuzzFailure.
All combinations of `-DsemiFuz` and `-DskipVm=true` would thus keep both
of those expectations.
For the combination `-DsemiFuzz=false -DskipVm=true` it actually passes,
though, which doesn't match so it fails saying that the expectations
should be updated.
For any of the other expectations it would be fine because it would get
one of the expected outcomes:
* `-DsemiFuzz=true -DskipVm=true`: Fuzzing is enabled so it would get a
SemiFuzzFailure which matches one of the expectations.
* `-DsemiFuzz=true -DskipVm=false`: Fuzzing is enabled so it would get a
SemiFuzzFailure which matches one of the expectations.
* `-DsemiFuzz=false -DskipVm=false`): It doesn't skip the VM so it gets
a RuntimeError which matches one of the expectations.
This CL fixes the issue by removing the "wrong" expectation(s), leaving
the correct one(s) and adding 'pass' of all other expectation(s) have
been removed.
Change-Id: I8137d16fdfeb322cb76d6af97cafc279222ae205
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/192921
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
We currently run our leak tests weekly.
This extends it so we also run leak tests with advanced invalidation,
as well as our strong and weak tests with fuzzing enabled.
Change-Id: I2c941f58594791d1981c6b6612db2205b68f5e19
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/192682
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Mayank Patke