In an upcoming CL, I will be replacing the FixBuilder with an
implementation that re-uses resolution logic from the analyzer. Due
to complexities with the analyzer's scope management, it won't be as
easy to test individual visit methods in isolation anymore, so this CL
modifies the FixBuilder tests so that they each visit an entire
compilation unit rather than just one or two AST nodes; this will
allow landing the rewritten FixBuilder without making further
significant test changes.
Note that in order to land this CL I had to had some temporary hacks
to the FixBuilder so that it could visit top level constructs
correctly. These hacks will go away when the rewritten FixBuilder is
landed.
Change-Id: Iffaaaa382070aa87c368e6fcc28034030a34b4ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/128484
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
- New flag: --clean will throw away the local playground at the beginning of the run
- New flag: --exception_node_only prints only the exception node
- New flag: -g allows fetching git repositories into a local playground
- New flag: -u automatically updates Git repositories with git pull
Change-Id: If8472cb9bb97b42fe649d6ec168850c740f84d6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/127702
Commit-Queue: Janice Collins <jcollins@google.com>
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
This prevents the following crash:
Bad state: Missing declarated type annotation in /home/test/lib/test.dart; for Object
package:nnbd_migration/src/variables.dart 68:7 Variables.decoratedTypeAnnotation
package:nnbd_migration/src/edge_builder.dart 1378:26 EdgeBuilder.visitTypeName
package:analyzer/src/dart/ast/ast.dart 10012:49 TypeNameImpl.accept
package:nnbd_migration/src/edge_builder.dart 844:10 EdgeBuilder.visitIsExpression
package:analyzer/src/dart/ast/ast.dart 6372:49 IsExpressionImpl.accept
Change-Id: I23ed49ccbd3625d9f9fbc7e07a69be3c580896ff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/127457
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Imports a subprocess helper with JSON parsing borrowed from Dartdoc,
which will come in handy both for launching pub and for building the
trial migration script out for comparing output between versions.
Also puts some basic structure in to allow for fetching packages for
multiple sources.
Change-Id: I5262b93aa1d60005ee262b7ed00bf534b1c51447
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/127446
Commit-Queue: Janice Collins <jcollins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
FlowAnalysis.finish checks the proper nesting of begin/end calls to
flow analysis, but such nesting might not hold in the presence of
exceptions. As a result, if we call FlowAnalysis.finish from inside a
finally block, we may report an error due to the lack of proper
nesting, and lose the original cause of the exception.
In these exceptional circumstances, it is better to allow the original
cause of the exception to propagate to error reporting, since its
stacktrace will be closest to the site of the bug, rather than to have
it replaced by the error from finish().
Change-Id: I58b1bd4882362ff1e23c03dc8ba65e39655fc98f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125980
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Replace it with TypeSystem from lib/dart/element/type_system.dart,
or (internally) with TypeSystemImpl.
We keep the old TypeSystem where its is exposed from API:
- ResolveResult.typeSystem
- AnalysisSession.typeSystem
- AnalysisContext.typeSystem
We will make changes to these as a breaking change later.
Change-Id: I40ca53ea77e440457c6d0f3832ec3b6286bacdf0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125770
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Previously this was based on creating a dummy type pointing to `never`
and then trying to assign to it. Since we are trying to get rid of
explicit references to `never` outside of the graph logic, that isn't
going to work anymore. Refactor to just create the correct edge
directly using NullabilityGraph.makeNonNullable.
Change-Id: I18683bfe5e02924d2ccfcb0459047568734f975d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125801
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Previously we were using `neverClosure`, which made the tests very
lenient; they accepted any node with an edge pointing to `never`
through a sequence of zero or more hard edges to be non-nullable.
While it is true that any such edges will be migrated to be
non-nullable, in our test cases we nearly always know that we want the
node to point to `never` through exactly one edge. So it's worth
making the tests verify this.
Change-Id: I2783fd41628961e0cd31b95edd396defd0b26593
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125550
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
With this change, we no longer use the "never" graph node for:
- instance creations
- explicit references to `this` or `super`
- the static type of `throw` and `rethrow` expressions
Change-Id: I995be86ee0f4d8002c70cf98e7e5d2767529d00b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125226
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This eliminates a few direct references to `always` and `never` nodes
from the edge builder. It also fixes a latent bug where we were
failing to create a hard edge when handling "is" expressions.
Change-Id: I4c88432c97932eac3554cfcb75bbd634c0e2e4c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/125061
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
When migrating a reference to a field or top level variable, we have
to create a temporary type to represent the synthetic getter or setter
that is being referenced. That requires creating some new nullability
nodes, to represent (a) the `void` return type of the setter, and (b)
the function type of either the setter or the getter. These nodes
never actually get attached to the nullability graph (because a call
to a getter/setter can't access the function type, or the return type
of the setter), so it doesn't really matter what nodes we use.
This change switches to using fresh nullability nodes rather than
always and never for these inaccessible types. This takes us one step
closer to eliminating the use of always and never outside of the
implementation of the nullability graph itself.
Change-Id: I33de35ba36bbca42731c5e2d827ccf972cd368dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/124911
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Paul Berry