We're not currently working on this, and it has some dependencies that
interfere with publishing the migration tool. If we wind up needing
it again, we can always revert.
Change-Id: Ia6219ac376cef77bda7470777eaf2bebf38769b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149343
Commit-Queue: Janice Collins <jcollins@google.com>
Reviewed-by: Janice Collins <jcollins@google.com>
This code was necessary when the NNBD migration engine was part of the
analysis server, to allow migration to be run in-process. Now that
it's been separated to its own library, it always runs in process, so
this code is not needed anymore.
Change-Id: Id9e497dca6700ad804f2410cb3b20107be3a4bd2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148503
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Shifted some minor things around in the design as well -- particularly
the symlink is moved to being owned by the workspace as not all
workspace implementation will create symlinks in the original directory.
I've also dropped most of the public interface to FantasyWorkspace.
Will add that back in when I'm more sure what it will be.
Change-Id: I19d1b1c8ad4063868ff7c10869c4561d4db64bf2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/133435
Commit-Queue: Janice Collins <jcollins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Previously, we used the offset of an AST node as a unique ID to
represent it, with a special hack to make sure we can distinguish a
generic function type from its return type (which has the same
offset). But in an upcoming CL, I will need to start associating
unique IDs with expressions, so that will bring up a whole bunch more
ambiguity.
This CL switches to a technique where we combine the offset and the
end of any source span into a single unique identifier. The algorithm
produces an output that is no larger than the square of either input.
Since we have 64-bit integers in Dart, this should be adequate for any
reasonable input file size.
Change-Id: I68ce27533eb485cc824e1080326d02de98bff1e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/132404
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
This interface is a callback interface that allows the client to
receive detailed information about the decisions made by the migration
tool, and the source code locations associated with those decisions.
The idea is that a client of this interface can put together a report
to the user to help them understand the behavior of the migration
tool.
The instrumentation interface mostly exposes internals of the
migration engine through some safe, non-destructive interfaces. The
interface itself is documented in the new file
pkg/nnbd_migration/lib/instrumentation.dart. For examples of what
information the client can expect to receive through the
instrumentation interface, see the new file
pkg/nnbd_migration/test/instrumentation_test.dart.
Change-Id: I079551922bff75e0e8d290819f31533c29d7b62f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/117285
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
We now wrap named argument types in `{}` and optional positional
argument types in `[]`.
A few unit tests have been added to verify this functionality; I
didn't exhaustively test the implementation of DecoratedType though.
Change-Id: I1e3135adc3abc966f8a41d90c1c6e95e9c7c1eda
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107747
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The new data structure, called `DecoratedClassHierarchy`, computes and
caches the variable substitutions necessary to relate a class to one
of its superclasses. In future CLs, we'll use this information to
create the appropriate contraints for override relationships, and to
compute the correct types when a method dispatch resolves to a method
declared in a superclass.
Note that the analyzer uses `InhertanceManager2` both to determine
what a method call resolves to and to record the appropriate
substitutions. We can take advantage of its determination of what a
method call resolves to (that information is stored in the resolved
AST), but we need to cmopute the substitutions separately because the
substitutions need to be decorated with nullability nodes.
Change-Id: Ifb334972e509b77151d41f7e0700cd590d7b5417
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/106800
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
This gives us more flexibility for how we want to publish and deploy
the tool. We now have the option, for example, of making a command
line app that invokes the tool and does not depend on analysis_server.
Note that some testing infrastructure had to be duplicated. I plan to
consolidate this infrastructure in follow-up CLs.
Change-Id: I046506bc2bb5c3e467e15885f198ee0632351ee9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105463
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Paul Berry