We're going to move this file into _fe_analyzer_shared, so we can't
have it importing CompilerContext. It turns out that we were only
using it to cache the decision of whether to display colors, and to
decide whether to verbosely explain how we made that decision. Those
can be accomplished in other ways.
Change-Id: If1e3a9fee7c0ca919444d8429936045b8408c246
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123840
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Problem:
We have been having a lot of reports of failures when initializing the incremental compiler
(see https://github.com/dart-lang/sdk/issues/38102).
These appear to be the result of empty kernel files but we have added other logic to check
for that when kernel files are written, which has had zero reports of throwing from users
(https://github.com/dart-lang/build/pull/2387).
We also use the same mechanism for temp directory management as we did with analyzer, but only
see this problem with the switch to kernel, and specifically the incremental compiler.
Solution:
Add retry logic and see if that fixes the problem. Any time there is a retry log a warning
so that we don't just silently do retries all the time.
This is a general defensive mechanism to cover a broad spectrum of potential failures with the
incremental compiler in the wild. I don't intend to remove it as it isn't harmful, and the
warning logs should be enough to encourage issues to be filed if it is happening often.
I have no direct reason to believe this will actually solve the particular linked problem other
than that we only see this issue when the incremental compiler is enabled.
Bug: https://github.com/dart-lang/sdk/issues/39122, https://github.com/dart-lang/sdk/issues/38102
Change-Id: Iaabb4497d6da69684692c1d7b9c030c59ebc6072
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123001
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
This moves the five test suites for flow analysis along with the
constants test suite.
Note that a few files have formatting errors. I'll fix those in a
follow-up CL.
Change-Id: Ie9bba74c7d91e49ac6c9d3c64a96be007b6a94c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123680
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Previously such shared code was in the front_end package, but that
created problems because there is a lot of code in front_end that
isn't intended to be shared with the analyzer (including, notably, the
dependency on kernel).
This CL just moves over the flow_analysis logic to the new shared
package. Follow-up CLs will move over other shared logic and tests.
The end goal is that the analyzer package will no longer have a
dependency on front_end.
Change-Id: I5642d6565204422d79808ca47648462db85e442a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123624
Reviewed-by: Jens Johansen <jensj@google.com>
Flow analysis requies the client to desugar a try/catch/finally
statement into a try/catch statement nested inside a try/finally
statement (or, in the analyzer's case, to make calls to flow analysis
as though such a desugaring has been done). The analyzer was doing
this incorrectly:
- It was always calling the flow analysis methods for try/catch, even
if there were no catch clauses present.
- When calling tryFinallyStatement_finallyBegin for a
try/catch/finally statement, it was passing in the node associated
with the original try block (prior to "desugaring"). It needs to
pass in the node associated with the desugared try block (which
includes the catches).
Includes a similar fix in the migration engine.
Fixes#39178.
Change-Id: I16440e71d4964b9905fc2316380c8c98f14b13f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123506
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is needed by the front end, since it sometimes finishes parsing a
construct before creating the kernel representation of it, so it needs
to defer storing the node info for that construct until it creates the
kernel representation.
Change-Id: I2a59f08a228b6fed2af711cc0f06576ddc99a054
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123505
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
- Don't state that any word not found in the dictionary is a misspelled
word. Instead say it's not found in the dictionary. If the word was
found in the blacklist, say that.
- Offer alternative spellings if a word in the dictionary is 'close'.
E.g. if I typed 'explicitley' offer 'explicitly' as an alternative.
- Tell where the dictionaries are located to make it easier to add new
words.
Change-Id: I85ee622ffd8a36c7d77b82cb64809ec005f5fefb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123522
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This will need to be used by the front end's body builder to properly
record assigned variables for a try/catch/finally statement.
Change-Id: Ia0cda160e524f6dc52c19362cc35b6f405eca993
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123501
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
This avoids the need to special case test expectations for CFE in
pkg/front_end/test/flow_analysis/reachability/data/never_return_type.dart.
Change-Id: Ib754a76c96e73c8183b5ff10a2e7d2908e653a31
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123420
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This allows so-called "ensure guarded" promotions, e.g.
- `if (x is! int) x = 0;`
- `if (x == null) x = 0;`
- `x ??= 0;`
The latter two are particularly important to prepare for NNBD.
Change-Id: Ib53ca916e6d485945326b19e86f8cfb5b3ee2160
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123280
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, we made heavy use of operator== in the flow analysis
tests. But we also tried to verify that the flow analysis engine
didn't compare types with operator==. This was kludgy, because it
meant that we had to use a global variable to keep track of whether a
use of _Type.operator== should succeed. It was also kludgy because it
required an implementation of operator== in flow analysis code that
was solely meant for testing.
By using custom matchers, we can get the same level of testing
flexibility without making use of operator== anywhere.
Also, fixed a few flaws in the tests for "join". They were
accidentally setting up variables in the already-written state, so the
"assigned" subtest was passing in spite of incorrect expectations.
Change-Id: If326678aeb20a62433ad090968e150738ba5dc59
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123140
Reviewed-by: Johnni Winther <johnniwinther@google.com>
If the RHS of an assignment is a subtype of the current promoted type
(or one of the previously promoted types), any relevant promotions are
kept.
So for example:
if (x is int) {
x = x + 1; // Still an int!
print(x.isEVen); // ok
}
This required two significant changes:
- Clients must now tell the flow analysis engine the type of the RHS
of the assignment. This required some refactoring in the analyzer,
because this information wasn't always easily available at the point
where we were calling flow analysis.
- The flow analysis engine now has to keep track of a "chain" of the
currently active promotions, so that it can potentially un-do some
promotions but not others. This meant that the algorithms for
"join" and "restrict" had to be reworked.
In a future CL I'll add the ability for assignments to promote to
types that have been previously checked against ("types of interest"),
e.g.:
if (x is! int) {
x = 0; // x is now an int!
}
// x is now known to be an int because it's promoted in both branches
Change-Id: I63d6c9a2021b045d391b2d9c674e9a2e5f770e62
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123003
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This should make it easier to verify that the CFE implementation is
correct.
Note that this effort encountered a few bugs in the analyzer
implementation, which are marked with TODOs. I will fix them in
follow-up CLs.
Change-Id: Ic164a1cf214b5730f848b17db2838c29d25b00d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122850
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Before this CL a part like "part ' package:foo/bar.dart';" would crash
the incremental compiler because the part specifies a scheme that is
invalid.
Change-Id: I567df0a68ff8709e4ca95d24e6dabc4d959c95fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122862
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Previously, the client was responsible for querying AssignedVariables
to find the variables assigned and captured during constructs like
loops, and passing that information into FlowAnalysis methods. With
this CL, the client simply passes AssignedVariables into the
FlowAnalysis constructor, and the lookup happens automatically.
Change-Id: Ifbbf8ba8ea0d0f8a31d41244892c8c816eea56dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122731
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Johnni Winther