When visiting an assignment target that is an index expression
(`x[y]`) we'll need to know whether we are doing a compound assignment
or not, because this will influence whether the type context for the
index expression (`y`) should come from `operator[]` or `operator[]=`.
So before adding index expression support to FixBuilder, let's add an
`isCompound` boolean to indicate whether the assignment context is a
compound assignment or not.
Change-Id: I26a41544e10ef9c9ba042c1d7862563bd9d18b68
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121407
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
A few changes here:
- Prefix expressions didn't support dynamic invocations.
- Prefix expressions didn't support generic types.
- Postfix expressions were handled incorrectly (we used the return
type of operator+ for `x++`, whereas the type should have been the
same as the type of `x`).
Change-Id: I35077b82a6e9c4e4f6ad8bb1264f5d725ec0d9a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121401
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Instead of forcing the client to provide a way to de-parenthesize an
expression, the client informs flow analysis when a parenthesized
expression is encountered. This reduces the runtime overhead to zero
for non-parenthesized expressions, and it saves the front end from
having to worry about support for parenthesized expressions (since its
internal representation doesn't care about parentheses).
Change-Id: I0bb6e91c87acaa05591e1b075da18700b11e4aae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/121080
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
This moves the logic for detecting the patterns `variable == null` and
`null == variable` into flow analysis, so that they don't need to be
replicated in each client. It also opens the door to potential future
improvements (e.g. allowing `x == expr` to promote `x` to non-nullable
if expr has a non-nullable type).
Change-Id: I51fd9df822e3df1eb8bad5884f767c8b61c496ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/120934
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Rather than suppress all promotions for variables written to in
closures, we track whether a closure might exist that captures a write
to a variable, and only suppress promotions once such a closure
exists. This is consistent with what is proposed in
https://github.com/dart-lang/language/pull/473.
Contains a repro of #38791.
Change-Id: I4683581908703b510a3231b8fa8ed697121b09da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/120680
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Previously, we considered a variable to be captured by a closure if a
write to that variable occurred anywhere inside a local function. But
that was overly broad; it meant that we incorrectly classified all
written-to local variables of a local function to be captured.
This CL makes the AssignedVariables logic aware of variable
declaration sites, so that it only considers a variable to be captured
if it is written to at a lower level of local function nesting than
its declaration. As a side bonus, it means that it can now exclude
out-of-scope variables from all sets of closed-upon and written-to
variables, which should make flow analysis faster by preventing it
from spending a lot of time accounting for variables that aren't
visible.
It also adds tracking of the set of all variables written to and
captured within each top level function.
This partially reverts commit 55466fd3cc.
Change-Id: Ibcd6476445addebed13cfc5ecc470d644e519148
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/120800
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
There's no good reason to unify the flow analysis for several
variables declared together, and it would break some assertions I'm
going to add to flow analysis in future CLs.
Change-Id: I4dafb7b5e9b078cb741d506cd0bbfab1bcab5ebb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/120840
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
In a follow-up CL, I'm going to add logic to track the complete set of
assigned and captured variables seen so far. We will need these sets
in order to properly cancel promotions on entry to a closure or nested
function. But for performance reasons we don't want these sets to
include all variables seen in the entire file; just the local function
is sufficient.
Change-Id: I32a42075916be791f2fb7798814cec4c020e8b3b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/120751
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This makes trial_migration.dart report two new exceptions:
_EdgeBuilder&GeneralizingAstVisitor&_AssignmentChecker._checkAssignment (package:nnbd_migration/src/edge_builder.dart:2169:14) (x30)
_EdgeBuilder&GeneralizingAstVisitor&_AssignmentChecker._checkDowncast (package:nnbd_migration/src/edge_builder.dart:2351:14) (x7)
30 & 7 is not great but not terrible. These also do not break path, logging, or
charcode.
Failing tests show why we cannot correctly cover remaining cases without
a larger CL.
Change-Id: I6e510db147f60cc8ee047d45e4ce2d95d26cccc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119533
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
This visitor, once completed, will visit code after migration is
complete, determining the post-migration type of each expression, and
deciding where null checks are needed.
See #38472 for more information about why this is necessary.
Change-Id: I8c7dece643cf5417dbb66d5290fcdbad68d3e690
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119400
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
It is no longer necessary to explicitly "add" variables that are
subject to flow analysis. Unrecognized variables are now treated
simply as uninitialized. This simplifies analyzer error recovery by
ensuring that an attempt to use a variable before its declaration
doesn't lead to a crash.
Change-Id: I11e8afc3ffb93c864db4638a224ff782d11f5a6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119200
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Now that the migration tool inserts `required` rather than `@required`
for required parameters, we need the trial_migration tool to
understand the new behavior.
Change-Id: I401310930120cf6e57af7ab633983b44415d404f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/119081
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Details provide a way for clients to provide navigation support. I'm
imagining that the description could be used as link text.
The deatils are currently more of a data dump than information. I need
to see more migration results in order to figure out when and how to
pare down the data into actionable information.
We might want to capture all of the navigation targets as we build the
info so that we can create anchors in the HTML.
Change-Id: Ie48622ce7d935d3c028ea42e51cfc8da590db149
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/118908
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Konstantin Shcheglov