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>
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>
When performing flow analysis for a "for each" loop such as `for (var
x in ...) { ... }`, we don't need to consider the iterated value to be
"written to" the variable `x`, since the actual runtime semantics are
to create a fresh instance of the variable `x` each time through the
loop, initialized to the iterated value.
Fixes#43136.
Bug: https://github.com/dart-lang/sdk/issues/43136
Change-Id: I497c408c3efc26e93502de8ba0530bb5278e74c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/162581
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously the flow analysis equations for a for-each loop `N` of the
form `for (var V in E) S` were approximately as follows:
- Let `before(E) = before(N)`
- Let `before(S) = conservativeJoin(after(E), assignedIn(N), capturedIn(N))`
- Let `after(N) = join(after(E), break(S))`
This CL changes the behavior to:
- Let `before(E) = before(N)`
- Let `before(S) = conservativeJoin(after(E), assignedIn(N), capturedIn(N))`
- Let `after(N) = join(before(S), break(S))`
(In other words, the result of the conservative join is carried
through to the state after the loop). This isn't strictly necessary
for soundness, but it makes the behavior of a for-each loop more
consistent with its desugared equivalent. In particular, it means
that if a variable is potentially assigned to or captured in the body
of the loop, then the effect of that potential assignment or capture
will be felt in the code that follows the loop, even if the potential
assignment or capture is not connected to the flow control path.
Change-Id: I7a70a8ae9f87bd40b6592992d8ee985a9aa87e80
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/162480
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
* Add mechanisms to try out a recovery and only perform it if is
successful.
* Recover written out binary operators, e.g. "a xor b", "a or b" etc.
This fixes#26810 and is also how these operators are written in e.g.
Kotlin. This might be somewhat controversial though.
* Adds a mechanism to _replace_ a token by another token.
This might be controversial.
It is done because just inserting the operator causes the same rewrite
to be attempted on the same token stream several times (at least with
the way the token stream is parsed via the CFE) in turn causing it to
be recovered *sometimes*. This is now avoided by actually replacing
the token.
Change-Id: Icfa806045575d2aa2e5f35126708651b275bcf84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/162003
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL improves recovery in situations like this:
typedef c = foo(int x);
=> recovers like typedef c = foo Function(int x);
typedef d = (int x);
=> recovers like typedef d = Function(int x);
typedef e = foo<F>(int x);
=> recovers like typedef e = foo<F> Function(int x);
typedef f = <F>(int x);
=> recovers like Function<F>(int x);
typedef g = foo<F, G, H, I, J>(int x);
=> recovers like typedef g = foo<F, G, H, I, J> Function(int x);
typedef h = <F, G, H, I, J>(int x);
=> recovers like typedef h = Function<F, G, H, I, J>(int x);
typedef i = <F, G, H, I, J>;
=> recovers like typedef i = Function<F, G, H, I, J>();
And appropriate error messages are given:
"Expected 'Function' before this." and (when inserting parenthesis)
"A typedef needs an explicit list of parameters.".
Fixes#26073.
Change-Id: I368f36f2993033d62b36315198bc993eed74bc92
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/161485
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL also adds fileUri/charOffset to all TypeBuilder's and renames
Void/FutureOr/Never/Dynamic/BuiltInTypeBuilder to *TypeDeclarationBuilder
so match their relation to TypeBuilder/TypeDeclarationBuilder.
Closes#42962
Change-Id: Iee5102134574d24f748103282a37bb9a85a0ac2d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/161165
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This CL:
* Changes the events so beginX and endX events always comes in pairs
(though technically not right as some specific events can be beginX
endY --- but in those cases it is at least documented and used in code
that actually tests it).
-> This entails adding some events and converting something from
"beginX" to "handleX" instead.
* Adds a utility that can generate an AST of sorts directly from the
parser via a listener using the begin/end matching (and knowing of the
specific ones that doesn't match directly).
* Adds a test that checks that - at least for all tested (50,000+) files
- the AST actually generate "correctly", i.e. matches up begin/ends
and ends up with a single top entry "CompilationUnit".
* Adds a different visualization to the parser listener events by
displaying the "AST directly from the parser" in a UI that can be
navigated. The visualization may not be the best, but it's certainly
a stepping stone.
Change-Id: I9b27f7bbf3be442adc92f357c7b3c46da6f84cf7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/159664
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
If an identifier starts with a non-ascii-character and has a comment
an assert was triggered about the comment not being attached to the
token. This CL attaches the comment to the token (which it should be)
and thus avoiding the assert trigger.
Change-Id: Id261970b88ca721d4b3a996abfb8ff43f0ec8341
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/161102
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Paul Berry