Main risk in this CL is that it deviates from the void work which I'm confident is exhaustive.
Particularly, operators on void are caught by the resolver as a special kind of missing method, hopefully I put all the syntactic checks in at all the necessary places.
I also hardcoded "toString()," "hashCode." I previously had hardcoded to allow "==" checks, however, the code in ErrorVerifier was tripping over that. So now it should be good.
Change-Id: I56abb0219feb7aa143159694b688be15ba29015c
Reviewed-on: https://dart-review.googlesource.com/c/92063
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL also contains changes from another CL.
Add missing generics in FlowAnalysis.
I can wait until that CL lands, and rebase, if it helps.
This CL also switches to a different approach to handle try / finally,
using two parallel states instead of 'restrict'.
R=paulberry@google.com
Change-Id: I1ca5bed3b4362cb3bdca5abf36c849c59538e57e
Reviewed-on: https://dart-review.googlesource.com/c/92246
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
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>
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>
Previously we had a bug, when a library linked summary was computed,
and then a part of this library is incorrectly imported as a library,
the implementation of `transitiveSignature` was returning the
signature of the containing library, so we would use the linked library
of the actual library, but the unlinked summary of the part file.
R=brianwilkerson@google.com
Bug: https://github.com/dart-lang/sdk/issues/35621
Change-Id: If225136de4e6576f0499d2318a67c721d80d17ae
Reviewed-on: https://dart-review.googlesource.com/c/91855
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
The two interface classes make it clearer which methods are intended
to be used by ConstraintGatherer vs. ConstraintVariableGatherer, and
refactoring DecoratedType.forElement paves the way for a future CL
that will handle constraints on inferred types.
Change-Id: Ibd2f22ea9d38df7be1c4da0e4eef2006556b7351
Reviewed-on: https://dart-review.googlesource.com/c/91851
Auto-Submit: Paul Berry <paulberry@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Brian Wilkerson