This CL fixes the wrong message, so - when in the process of fixing
the package nnbd settings - one gets the correct message, mentioning the
right packages and no longer mentioning the fixed ones.
Change-Id: Ied26094055e56b44dfdd2e942b98eb9e1e7968fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170423
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This fixes the issue of the error not going away, but can (see added
test) give a wrong error message when in the process of fixing the issues.
A follow-up CL will (try to) correct the wrong error message.
Change-Id: I3547fe5fb5cfd179897996029a00a4995a967e54
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170422
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The `bool` return types were added to `FlowAnalysis` methods
`nullAwareAccess_rightBegin`, `ifNullExpression_rightBegin`,
`equalityOp_end`, and `isExpression_end` in September as part of an
effort to fix mixed-mode unsoundness loopholes by having the front end
throw exceptions if "impossible" conditions arose. We later decided
that we would prefer to allow these conditions to arise without
generating exceptions, because that makes it easier for the user to
write defensive mixed-mode code. So the booleans stopped being used.
This CL removes them entirely.
Change-Id: Ia0ff91a22fe79c2df1dea89bbb286c84a3603821
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170125
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The added messages handle the situation in which null safety is enabled
by default but is turned off either by language version or by explicitly
passing --enable-experiment=no-non-nullable
Change-Id: Iec43daf19a80f555e838635c83542fdb243b8ed4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168647
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
- make sure nested blocks scopes are visited
- make sure variable definitions do not leak beyond block scopes
- properly collect scopes for loops, if statements, constructors
- add calculation of fileEndOffsets for blocks
- save block file offsets to dill
- update binary format version
- change kernel readers and writers to read and write block offsets
- change vm readers to read and block offsets for new version
- add missing fileOffsets and fileEndOffsets on functions for
late fields
- add missing fileOffsets and fileEndOffsets on functions for
extensions
- add errors on failures to find scope
- find libraries for private fields correctly
- add more expression compilation tests
- add test to verify fileOffsets and fileEndOffsets are set for
SDK summary (will add full dill tests later)
Closes: https://github.com/dart-lang/sdk/issues/40278
Related: https://github.com/dart-lang/sdk/issues/34942
Change-Id: I5bc1bb645543045b689d8d61069ee77dc4ee9025
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167541
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The recent changes to `for` statements were necessary to ensure that
if a `for` statement causes type promotion due to an unreachable
branch without type promotion joining a reachable one with type
promotion, the type promotion would still happen properly even if the
top of the `for` statement was itself unreachable. There is no need
for a similar change to `for each` statements, because they are simple
enough that this situation cannot arise. But it's still worth making
the corresponding change for consistency.
Bug: https://github.com/dart-lang/sdk/issues/40009
Change-Id: Idabf7745f04a99152e688bf050a8d80e07b004e2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166520
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The setReachable method took a bool indicating whether the new state
should be considered reachable or not, however outside of tests the
value that was passed in was always `false`. Change to a
`setUnreachable` method taking no arguments.
This should make it easier to transition to a stack representation for
reachability.
Bug: https://github.com/dart-lang/sdk/issues/40009
Change-Id: I16a35ec3d5f44763a60e42f200a3caa619fac118
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/165142
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This increases our "local" coverage of the constant evaluator.
Run with something like
`pkg/front_end/test/fasta/strong_tester.dart -DupdateExpectations=true -DstressConstantEvaluator=true -DskipVm=true`
there is now almost coverage of everything (or a comment in the code
suggests that the path is probably unreachable).
Note that
`out/ReleaseX64/dart pkg/front_end/test/vm_service_coverage_constant_evaluator.dart pkg/front_end/test/fasta/strong_tester.dart -DupdateExpectations=true -DstressConstantEvaluator=true -DskipVm=true`
has erroneous misses, for instance (but not limited to) asserts.
These are caused by errors in the VM.
A follow-up CL will be created to turn on "stressConstantEvaluator" by
default and print out any sucesses in the expect files.
Change-Id: I837837be4f0487fdbe57c5107e4b3415de189177
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/163060
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The CFE defers the final build of the body of a for-element until
after building the rest of the body. This caused a bug: if the body
was an assignment expression, flow analysis was not picking up on the
fact that the assignment was inside the loop.
Fixed by introducing a mechanism that allows the CFE to temporarily
pop the innermost structure on the AssignedVariables stack and then
push it again.
Change-Id: I11d526302934e9283807124ebd4a23e9d3e5ec66
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/164980
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
A late variable with an initializer is very similar to a function
expression, in that it may be evaluated at any time in the future
(possibly more than once, if it throws an exception), so flow analysis
models it that way.
Fixes#42990.
Change-Id: I90ed00c8fd7388145f89011628e31ff7e85a5c43
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/164420
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Checks to see if a JS interop member is correctly annotated with
the `external` keyword. If it is not, it must be one of several
exceptions to be allowed.
This CL also changes static errors to first check for `JS` and
`external` before processing the member as a JS interop member.
This makes it clearer whether a member is a JS member.
Change-Id: I412eeafbfe8773847bfb9c864e4fb9b65e2d632a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158083
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This requires a change to flow analysis that does not promote
expressions to Never through is-tests and equality tests.
Change-Id: Iec2ba5b78e61d205ad21dad6f07dbdb25fc746d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/163380
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Previously, we did not permit a final local variable without an initializer.
This allows constructions like:
final int i;
if (...) {
i = 0;
} else {
i = 1;
}
use(i);
Change-Id: I0ca20c810993627c70ce84a9ad238e683df41595
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/163702
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Jens Johansen