This allows us to remove a substantial amount of CFE and analyzer
code.
It also fixes a minor CFE type promotion bug
(language_2/type_promotion/assignment_defeats_promotion_lhs_and_test).
TEST=standard trybots
Change-Id: Ia0c159bdb9161d73648c9eb73b92822168f28d84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175583
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The ID test offset for a prefixed identifier is now the offset of the
identifier after the `.`. This makes the analyzer and CFE behaviors
match much more closely, which eliminates a lot of nuisance
differences in the ID test expectations.
Change-Id: Icef1b2bf56b79bcf584d1eb153bdafd575e6cabb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/195483
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Previously, if a type mismatch occurred on a named argument, e.g.:
int.fromEnvironment('foo', defaultValue: 'BAD')
the error would be reported on the entire NamedExpression
(`defaultValue: 'BAD'` in this example). Now, the error is just
reported on the expression (`'BAD'` in this example). This makes the
analyzer behavior more self-consistent (since now assignability errors
are now consistently reported at the site of the expression that can't
be assigned). It also makes the analyzer behavior more consistent
with the CFE.
This will make it possible, in a follow-up CL, to eliminate a lot of
the inconsistencies between analyzer and CFE in the "why not promoted"
ID tests.
Change-Id: I17db256959d730a22a5766f65d5c0736b627f244
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/195489
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is a simple string-based intermediate representation for Dart
code, similar to kernel but with a far simpler structure and a compact
string encoding, suitable for use in unit tests.
I've integrated this representation into mini_ast.dart in a
preliminary way, so it is created as a by-product of running flow
analysis tests. But as yet there are no tests that validate the
correctness of the result. I plan to refine the representation, and
test it fully, in follow-up CLs.
Change-Id: Idda527efd005d0199ff88861c9e074eb651d82f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193881
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This paves the way for generalizing the "mini AST" code so that it can
do full type analysis.
For the moment, the context parameter is always `unknownType`. In
later CLs I will thread the appropriate context types through the
system.
Change-Id: I5d5e0d6644dba590234e363d1d5d0720bdb71d30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194660
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The new class, _MiniAstTypeAnalyzer, currently only handles the "mini
AST" representation we use for flow analysis tests. In follow up CLs
I plan to extract a base class from it that will be general enough to
form the basis of a shared type analysis engine for the analyzer and
the CFE.
Change-Id: I180e1484aff1733146ccf73bcab5604e9f4ef2f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194620
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Now that we store the body of a try statement as a separate Statement
object, we can use it directly; it's not necessary to create a
synthetic node for it. This is more similar to what the analyzer and
CFE do.
Change-Id: I7c9a62aa917e966f0dd176f90b72865a38addd65
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194545
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This makes the flow analysis tests more similar to the anaylzer and
CFE implementations, which look up the type of a `this.` property get
at the time it is analyzed, rather than storing it in the AST node.
Change-Id: Idee2a9c3ba0acbd2752db511c1aabfdff075b363
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194544
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Two changes:
- Eliminate the `_Visitable` class, which was no longer used.
- Stop passing flow analysis as an argument to the _visit methods;
instead access it through the Harness class. This paves the way for
future changes that will generalize this code for testing things
other than flow analysis.
Change-Id: I94e9208e9eec6f16c03160efa1f676e57d47a59f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194541
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
There's no harm in making the TypeOperations object available to
clients, and it will make it easier in the future to create other
shared analysis based on flow analysis.
Change-Id: Id6b603ab2a7baa64d423c87bf031ff6a12874840
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194501
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Flow analysis unit tests now support implicit branch targets, and use
`LabeledStatement` directly in the case where the branch target is
explicit. This is more similar to how the language acutally behaves,
and paves the way for adding more sophisticated tests in the future.
Note that at the moment, there are no flow analysis tests where a
`continue` statement has a different target than the innermost loop,
so for now, the `continue_` function doesn't accept a target
parameter. I plan to add this functionality in the future, at the
time that I add tests that require it.
Change-Id: I2591ee3322ea4adba3e32dc76a29f0b3956058e5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194040
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
For convenience in creating tests, the public mini_ast methods for
creating constructs like loops, try/catch, etc. accept lists of
statements as an argument where technically the language would expect
a single statement. This CL changes the internal representation so
that each of these statement lists is converted into a single
statement by wrapping it in a block.
This makes the mini_ast representation more closely match the
representation used internally by the analyzer and CFE.
Change-Id: If2bf8a1cde694206b91b57c5907806b1965d4d99
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193880
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL changes the responsibility for doing flow analysis of the
implicit variable write in a `for-in` loop as follows: if the `for-in`
loop does not declare a variable, but it assigns to a local variable,
then the flow analysis client is responsible for calling `write` on
entry to the loop.
This in turn allows us to use a single code path to track "why not
promoted" information related to all possible local variable writes;
we no longer need as much special case logic to handle for-in loops.
To make the analyzer integration slightly cleaner, we change the
argument type of FlowAnalysis.write to Node rather than Expression, so
that the analyzer can pass in the ForEachParts object when analyzing a
for-in loop.
Bug: https://github.com/dart-lang/sdk/issues/44898
Change-Id: I24b47be8eac2e276cd291a5b2f2e4444c911138f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193837
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is clearer because:
- The use of "could not be promoted" is consistent with the other "why
not promoted" messages.
- We avoid speculating about whether the variable might be assigned a
null value; this should help avoid confusion in cases where the user
can see that assigning a null value is impossible, but promotion
still fails.
- We avoid the phrase "intervening write", which is a little too
erudite.
Bug: https://github.com/dart-lang/sdk/issues/44898
Change-Id: I0b8a2132dc99dd06769677f98e6257e9b55ad9d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193820
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This makes the flow analysis unit tests more similar to the behavior
of the analyzer and CFE, in that the types of various properties are a
property of the program being analyzed, not of the individual property
gets themselves.
Change-Id: I6ea164665093ee285325a64e80f3f52d7a63cf74
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193836
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The ID tests for the "why not promoted" feature had some minor
unintentional errors in them. This CL fixes them:
- The constructor tests in
argument_type_not_assignable_nullability_error.dart tried to return
null from functions whose return type didn't allow it.
- The compoundAssignmentRhs test in
argument_type_not_assignable_nullability_error.dart tried to add an
`int` to an `int?`. The CFE considers this to be an error, but also
reports a follow-on error because it thinks the type of the
resulting expression is `num` (which is not assignable back to
`int`). To avoid the follow-on error, we use `num` for the type of
the variable to which compound assignment is being applied.
- The forElementInMap test in
for_in_loop_type_not_iterable_nullability_error.dart wasn't a proper
map (it contained two `null` elements, rather than a single map
entry `null: null`, which was what was intended).
There were also several tests for which we *don't* expect "why not
promoted" information; I added comments explaining why.
Change-Id: I91ddb88cb0f25f9b209df3eeb75d57d8270f877b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193561
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Rather than representing an assignment differently depending on what
kind of construct appears on its left hand side (as kernel does), we
represent all assignments as a single `_Write` type, and use an
`LValue` base class to represent the different kinds of constructs
that can appear on the left hand side. This representation will be
easier to expand into supporting more of the Dart language as we
expand the testing we want to be able to do in _fe_analyzer_shared.
Change-Id: I87b811176b2ba132fb992414c277cf2c6b81e03c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193180
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Add helper on DartType to compute the `NonNull` of a type and use this
instead of `withDeclaredNullability(Nullability.nonNullable).
Includes a fix in the computation of NonNull of FutureOr.
TEST=existing
Change-Id: I3399cbf89c7d3f3e90f1315b01f40957e798a1b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193400
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
We now use a single AST node to represent try/catch/finally rather
than separate try/catch and try/finally nodes. This more closely
parallels the data structures used by the analyzer and CFE.
Change-Id: Ic4c1f1e4ac9e10ebf36afa4047c9c8b9ce151a1f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193093
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The type of `this` is now stored in the test harness rather than in
the individual `this` AST objects. This more closely parallels how
`this` is handled in the analyzer and CFE.
Change-Id: I7c60aec8a14680beecca161ad25d681b82f79a2b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193092
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Konstantin Shcheglov