This CL adds support for the following scenarios to the analyzer:
- Attempt to use a non-promoted nullable expression as the iterable of
a for-in loop
- Attempt to use a non-promoted nullable expression as the argument of
a `yield *` statement
- Attempt to implicitly invoke `.call` on a non-promoted nullable
expression
- Attempt to use a non-promoted nullable expression as the argument of
a spread operator (`...`) that is not null-aware
Some of these cases are already handled by the CFE. Others will be
addressed in a follow-up CL.
Change-Id: I3cf31b1496e1bd92fdd3f8192f04c98dff15077c
Bug: https://github.com/dart-lang/sdk/issues/44898
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/186320
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The MergeVisitor was trying to merge FunctionType.typedefType in order
to merge function types, thus preventing nnbd top merge of two
compatible types that were just introduced through different typedefs
or function type syntax.
Change-Id: Icea75598168c86ed33314db22ebeec3e666c3675
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184785
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
When reporting that a null check is needed due to a lack of type
promotion, and the thing that was not promoted was a reference to a
field or property, the CFE and analyzer now report "why not promoted"
using a context message that points to the definition of the field or
getter. (Previously the CFE reported a context message with no
location, and the analyzer didn't report "why not promoted").
Bug: https://github.com/dart-lang/sdk/issues/44898
Change-Id: If1841727b8b60dd87c43f239e6a06b98f363801f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184522
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL implements the core flow analysis infrastructure for tracking
reasons why an expression was not promoted. It supports the following
reasons:
- Expression was a property access
- Expression has been written to since it was promoted
I expect to add support for other non-promotion reasons in the future,
for example:
- `this` cannot be promoted
- Expression has been write captured
- Expression was a reference to a static field or top level variable
These non-promotion reasons are plumbed through to the CFE and
analyzer for the purpose of making errors easier for the user to
understand. For example, given the following code:
class C {
int? i;
f() {
if (i == null) return;
print(i.isEven);
}
}
The front end now prints:
../../tmp/test.dart:5:13: Error: Property 'isEven' cannot be accessed on 'int?' because it is potentially null.
Try accessing using ?. instead.
print(i.isEven);
^^^^^^
Context: 'i' refers to a property so it could not be promoted.
Much work still needs to be done to round out this feature, for example:
- Currently the analyzer only shows the new "why not promoted"
messages when the "--verbose" flag is specified; this means the
feature is unlikely to be noticed by users.
- Currently the analyzer doesn't show a "why not promoted" message
when the non-promotion reason is that the expression is a property
access.
- We need one or more web pages explaining non-promotion reasons in
more detail so that the error messages can contain pointers to them.
- The analyzer and front end currently only show non-promotion reasons
for expressions of the form `x.y` where `x` fails to be promoted to
non-nullable. There are many other scenarios that should be
handled.
Change-Id: I0a12df74d0fc6274dfb3cb555abea81a75884231
Bug: https://github.com/dart-lang/sdk/issues/38773
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/181741
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
We now track the following additional information:
- All local variable reads and read captures (previously we only
tracked writes)
- For any conditional expression (`?:`) or if-test, the variables
written in the "then" branch
- For any logical and expression (`&&`), the variables written in the
right hand side of the expression
Tracking this information will allow us to implement legacy type
promotion as part of _fe_analyzer_shared, using the same API as flow
anaylsis, which will in turn allow a lot of front end and analyzer
code to be removed and simplified.
Change-Id: I01aaf64cefb989a4450c8e6d3a8373c1ca2b6dec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179980
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The new implementation uses the same API as flow analysis. This
should allow us to significantly simplify the CFE and analyzer, by
dropping their implementations of legacy type promotion in favor of
the shared implementation.
This CL just introduces the new implementation and unit tests for it;
it does not integrate it with the analyzer or CFE. I will follow up
with a CL that does the integration.
Change-Id: Ie07b3b39604d6a022ad42f3ae6b648a317c8af28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179560
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The only references that are promotable are references to variables,
however in the near future I'll be adding logic to flor analysis to
keep track of attempts to promote fields; this will require tracking
references to property gets as well as references to `this`, so we
need to start building up data structures to track those references.
Bug: https://github.com/dart-lang/sdk/issues/38773
Change-Id: I0e3fd44f580bb85db3e8f405675b66aa4069e455
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179280
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
These test harness methods now take strings rather than Type objects,
which should make the tests easier to read (and less work to write).
Change-Id: I160bb7a7a61116e18736d414d5a549971d851c02
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178883
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
When analyzing code like this with the
`allowLocalBooleanVarsToPromote` flag enabled, don't treat a variable
containing `null` as equivalent to a literal `null`. For example:
f(int? x) {
var y = null;
if (x != y) {
print(x + 1); // ERROR: x must be null checked.
}
}
The rationale is that flow analysis doesn't promote variables that are
known to be `null` to the `Null` type, so it seems like it would be
inconsistent if we used the fact that they're `null` to promote other
variables.
Bug: https://github.com/dart-lang/language/issues/1274
Change-Id: Icfa14104936a26732353921e3a29a840c53d4d52
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/176560
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL adds functionality to FlowAnalysis.variableRead so that if the
truth value of the variable is known to be correlated with other flow
analysis state, that state can be restored. This allows promotion
based on boolean variables in addition to boolean expressions, e.g.:
int? x = ...;
var xIsNotNull = x != null;
if (xIsNotNull) {
print(x + 1); // Ok; x is known to be non-null.
}
This functionality is not enabled yet; it is hidden behind the flag
`allowLocalBooleanVarsToPromoteByDefault`.
Bug: https://github.com/dart-lang/language/issues/1274
Change-Id: I2a0183b69d285193db7acb36cc6af5c34e165c2c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/176500
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL modifies flow analysis API so that when a variable is written
or initialized, if the written expression has non-trivial flow
analysis information, it is captured in the SsaNode associated with
the variable.
The stored information is not yet used; in a follow-up CL, I will add
the ability to retrieve it on a read and use it for promotions.
Bug: https://github.com/dart-lang/language/issues/1274
Change-Id: I1e2590205d4a0c59f4400a119f3d6b380a11414c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/176460
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
When https://github.com/dart-lang/language/issues/1274 (Infer
non-nullability from local boolean variables) is fixed, this algorithm
will replace the `restrict` algorithm is currently used at the bottom
of a try/finally statement to combine the flow models from the `try`
and `finally` blocks. The new algorithm has very similar behavior to
the old one, however since it is based on SSA nodes it (a) is able to
make slightly more promotions than the old one, and (b) will be able
to properly update SSA nodes so that local boolean variables assigned
inside a `try` block will be able to used for promotion after the
`finally` block.
The new functionality is hidden behind a flag for now, so there's no
customer-visible change yet.
Bug: https://github.com/dart-lang/language/issues/1274
Change-Id: I1d37f981688f58da1e5c6c7eee48f2319c997cef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174960
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This is the first step in a sequence of CLs to support type promotion
based on local boolean variables
(https://github.com/dart-lang/language/issues/1274). To do this, we
will need a way to reliably tell whether a variable's value has
changed from one point in program execution to another, and to
associate additional information with a particular value of a
variable. We'll accomplish both of these tasks by associating each
variable with a pointer to an "SSA node". This pointer is updated to
point to a fresh node whenever the variable is written to, or two
different possible values come together at a control flow join.
Note that when a variable is write captured, it becomes impossible to
track when/if its value might change Previously we tracked this using
a `writeCaptured` boolean; now we track it by setting the SSA node
pointer to `null`.
This CL just lays the groundwork infrastructure and unit tests it;
there is no user-visible change.
Bug: https://github.com/dart-lang/language/issues/1274
Change-Id: Id729390655c9371cba264816b418f6c0463e1758
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/176180
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Some notes.
1. `Token.next` is `Token?` because there are null(s) for comment tokens.
But I think that it is never `null` in code, because there is at
least EOF token. So, lots of `!` null checks.
2. `Link.tail` is never null when `isNotEmpty`, but the type system
cannot express it. So, some number of `!` null checks.
3. I keep assert(s) for now, and use comment
`// ignore: unnecessary_null_comparison`.
4. I disabled `can_get_rid_of_nnbd_issue_error`, I think it fails
because of changes in `_fe_analyzer_shared` language version.
Smoke test in google3 looks green.
https://test.corp.google.com/ui#id=OCL:346825148:BASE:346841611:1607632317129:6e87bf7
I have not tried yet full TAP, will do in the evening.
I have not tried yet Golem, or looked at benchmarks.
Change-Id: I651301e5d3a851dd77d73af960dac779cb0fc991
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175620
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Previously, the unit tests for flow analysis re-used the logic from
the _WrappedExpression class, which uses
FlowAnalysis.forwardExpression rather than
FlowAnalysis.parenthesizedExpression. As a result,
FlowAnalysis.parenthesizedExpression wasn't being unit tested.
Change-Id: I1905808fd3a7788cb15d28c82d773369c061da59
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175164
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, we didn't have a unit test to verify that variable
captures in nested contexts are propagated to enclosing contexts.
Change-Id: I579bce6d07f61119f44259f1fbf1da7f0800adde
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175102
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
In preparation for some flow anaylsis work I intend to do this month,
I want to make the flow analysis unit tests easier to understand and
maintain. This CL creates an AST representation that models just
enough of the Dart language to be able to do flow analysis testing, so
that when reading or writing a flow analysis unit test, instead of
having to remember the correct sequence of calls to FlowAnalysis to
model a given construct, you can just create a mini-AST representation
of the given construct and pass it to the flow analysis test harness.
The mini-AST model for expressions contains methods that can be used
to build larger expressions out of smaller ones, so a lot of code can
be modeled compactly. For example, to create a mini-AST model of the
statement `x = y && z == null;`, call
`x.write(y.read.and(z.read.eq(nullLiteral()))).stmt`.
Change-Id: I11e3882078fdc5797176019398db48011232cf35
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174560
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The `bool` return types were added to `FlowAnalysis` methods
`nullAwareAccess_rightBegin`, `ifNullExpression_rightBegin`,
`equalityOp_end`, and `isExpression_end` in September as part of an
effort to fix mixed-mode unsoundness loopholes by having the front end
throw exceptions if "impossible" conditions arose. We later decided
that we would prefer to allow these conditions to arise without
generating exceptions, because that makes it easier for the user to
write defensive mixed-mode code. So the booleans stopped being used.
This CL removes them entirely.
Change-Id: Ia0ff91a22fe79c2df1dea89bbb286c84a3603821
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170125
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>
Paul Berry