Flow analysis unit tests now support implicit branch targets, and use
`LabeledStatement` directly in the case where the branch target is
explicit. This is more similar to how the language acutally behaves,
and paves the way for adding more sophisticated tests in the future.
Note that at the moment, there are no flow analysis tests where a
`continue` statement has a different target than the innermost loop,
so for now, the `continue_` function doesn't accept a target
parameter. I plan to add this functionality in the future, at the
time that I add tests that require it.
Change-Id: I2591ee3322ea4adba3e32dc76a29f0b3956058e5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194040
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
For convenience in creating tests, the public mini_ast methods for
creating constructs like loops, try/catch, etc. accept lists of
statements as an argument where technically the language would expect
a single statement. This CL changes the internal representation so
that each of these statement lists is converted into a single
statement by wrapping it in a block.
This makes the mini_ast representation more closely match the
representation used internally by the analyzer and CFE.
Change-Id: If2bf8a1cde694206b91b57c5907806b1965d4d99
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193880
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@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>
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>
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>
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>
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>
Paul Berry