At this point the migration tool is beginning to make assumptions
about decisions the language team hasn't made yet, so I've created a
class to document those assumptions and allow us to test variants.
Change-Id: I4638d7f534cfa2dbd8460277351045c370377ff8
Reviewed-on: https://dart-review.googlesource.com/c/92394
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This allows us to try it out on substantial codebases (e.g. the
analyzer itself) without crashing, even though a lot of the underlying
logic is not yet complete.
Change-Id: I24a45eea1889f7d9afa30c0398f359d32ffb52ad
Reviewed-on: https://dart-review.googlesource.com/c/92404
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This required modifying the implementation of nullability migration so
that it no longer holds onto AST nodes, but instead records sources
and offsets. This will allow the tool to scale to large projects
since the AST for one file can be garbage collected while the AST for
another file is analyzed.
Additional changes:
- provisional_api_test.dart is updated so that it tests the API in two
ways: once feeding identical ASTs to prepareInput/processInput, and
once feeding conceptually equal (but not identical) ASTs.
- The internal analyzer API is changed so that the finish() method
simply returns a list of modifications, rather than a map from path
to modification list.
- Files are tracked by Source rather than by path.
- Modification objects remember their Source (this should pave the way
for allowing multiple files to be migrated in a single run of the
tool).
- The Variables class is split in two, with the methods needed for
testing in a private class inside migration_test.dart. These test
methods can retain pointers to AST nodes without creating
scalability problems for the production code.
Change-Id: Idd3f3b6893a25bb4294b4b4c820e20e4bc47ffd8
Reviewed-on: https://dart-review.googlesource.com/c/92220
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Instead of returning a list of SourceFileEdit objects, we now return a
list of SingleNullabilityFix objects. Each SingleNullabilityFix can
be queried to determine (a) which source file it applies to, (b) the
exact set of source edits to apply, and (c) the kind of change.
Future CLs will add the ability to query (d) the location of the
change, and (e) the reason for the change.
Change-Id: I5a42958ac70d1e39802efd5915d0856109b4a7db
Reviewed-on: https://dart-review.googlesource.com/c/92151
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This updates the dartfix tests to align with how the dartfix API
is implemented and is being used, and removes the now unnecessary
InconsistentAnalysisException guard code.
Change-Id: Id7230ecec4940097fd0f2d3c034f47262ddc94b5
Reviewed-on: https://dart-review.googlesource.com/c/91962
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
Limitations at this point:
- Only one file can be migrated at a time. If you try to migrate more
than one file, you will get an assertion failure.
- The ResolvedUnitResult passed to prepareInput must contain precisely
the same unit (in terms of `identical`) as the ResoledUnitResult
passed to processInput. Otherwise you will get an assertion
failure.
- There is not yet any way to query diagnostic information about the
migration (e.g. heuristic decisions that were made).
- Only a very small number of constructs can be successfully migrated
at this point.
- The implementation is not sensibly organized at this point. Most of
it is in the analyzer, and then wrapped in the analysis_server.
Really it all should go in the analysis_server.
I'll be working to rectify these limitations over the next few days,
which will probably involve a lot of rework under the hood. But
hopefully the API in provisional_api.dart should remain stable, so
that DartFix code can start being written against it.
Change-Id: Idc3ebab380448a812d5e83338789570e33c55af7
Reviewed-on: https://dart-review.googlesource.com/c/92020
Reviewed-by: Dan Rubel <danrubel@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
interest in receiving not yet imported code completions from specific
packages and libraries.
The design of this interaction aims to avoid forcing analysis server
to send every public symbol from dependent packages at every completion.
Instead, clients express interest in certain packages and/or libraries
and analysis server will notify with the entire set of symbols for
each of them only once. Then it is the client's responsibility to save
these pre-computed completions in memory, and analysis server can
instruct the client on how to union them with the base set of completion
suggestions at code completion time.
Bug: https://github.com/dart-lang/sdk/issues/35680
Change-Id: I42c6fddc5d8daa2b546daa81456c0992e3ef547d
Reviewed-on: https://dart-review.googlesource.com/c/90125
Commit-Queue: Ari Aye <ariaye@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL extends the dartfix protocol to allow specifying which
fixes should be applied. In summary:
* includedFixes - list of fix names to be applied
* includeRequiredFixes - bool indicating required fixes should be applied
* excludedFixes - list of fix names that should not be applied
Given that the client can specify the fixes to be included/excluded,
then the dartfix cmdline help text should include the list of known fixes.
Rather than hard code this in the dartfix client, a new edit.getDartfix
request has been added to return the list of known fixes.
Change-Id: I319f6f405a5d29757bf28b70b778a449f901bbef
Reviewed-on: https://dart-review.googlesource.com/c/91700
Commit-Queue: Dan Rubel <danrubel@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Konstantin Shcheglov