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>
When an explicitly defined type variable is used in an incorrect
variance position in a method (whether in the return or the
parameters), an error is emitted.
Change-Id: I7e49687579bb2ce6e293b052b657b98741cb04f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/122740
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
When I moved these tests from front_end to _fe_analyzer_shared, I
forgot to move the corresponding entries in analysis_options to
exclude them from analysis, causing spurious analyzer errors in
_fe_analyzer_shared.
Change-Id: Ibd651cd893be262f388758d9b09bbf1423967021
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123742
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
For people with an installed analyzer, it causes it to go into an
infinate loop when it's called .dart --- calling it .crash_dart instead
should fix it.
Change-Id: Ib21b67bc7efdc87afa7893f7ec8d6e64bcff9c29
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/123246
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Jens Johansen