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>
It turns out we didn't have enough id test coverage to tell that we
were passing the wrong value for `conditional_end`'s
`conditionalExpression` argument.
This change fixes the call site and adds an id test that would have
caught the bug.
Change-Id: Ie99b1b7045e757ee78d72fcb435222fd27d680d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166307
Reviewed-by: Johnni Winther <johnniwinther@google.com>
I'd always meant to test the cartesian product of possible
reachabilities for the `restrict` function. Due to a copy/paste error
I was missing one of the four possibilities.
Change-Id: I3a99c72051e7f12afd8f345d8c2dafe92d6e2c48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166220
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@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>
When flow analysis encounters a variable declaration of the form `var
x = expr;`, if the type of `expr` is `X&T`, then the variable is given
the inferred type `X`, but it is immediately promoted to `X&T`.
Change-Id: I2a5ffca3860ab009f0942e6efc641c1604ab6323
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/163840
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Paul Berry