In this CL, I do not change the signature of any EditBuilder code, as
it is public analyzer_plugin API. I only change doc comments and a few
impl nits here and there, to make more modern or idiomatic.
This CL is isolated this way so that when I do a copy to the
analysis_server_plugin package, the moves will be smaller, readable
diffs (almost zero diff, just imports and things like that).
Change-Id: Ibc8a5ddb9a679278dd7223a3e2d868fe21c4acef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363881
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
In the *Builder APIs, this is what has changed:
* Add a parameter to `writeOverride` called `setSelection` which
controls whether selection should be set.
* `_addCompilationUnitMemberInsertion` is made public as
`insertIntoUnitMember`. Callers can insert multiple things into a
unit member, so it's a pretty generic name.
* Improved handling of synthetic brackets for all existing add*
APIs, like `class A extends B`. Many fixes and refactorings will
now write brackets if necessary.
Change-Id: I7ed79793c8625ec922ab8de2cb9e6fc33d022b76
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362183
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Add `DartFileEditBuilder.addConstructorInsertion`, a replacement for
both `CorrectionUtils.prepareEnumNewConstructorLocation` and
`CorrectionUtils.prepareNewConstructorLocation`. Combining the two
APIs is made possible by adding enum support to _InsertionPreparer.
For example, constructors can be inserted after an enum value-list's
semicolon (if there is one), or after the last value (if there isn't).
Also:
* Refactor _InsertionPreparer a bit to be cleaner; in the constructor,
we determine whether we can grab the `NamedCompilationUnitMember`
members.
* Instead of storing a `_targetMember` as a field, which is only null-
checked, store a Boolean value for whether a target member was
found.
* Remove pre-nnbd support in `DartFileEditBuilder.writeParameter`.
Change-Id: I3e98ed906cf5ac82e464c502db5986d3761c3611
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361624
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
`addMethodInsert` and `addCaseClauseAtEndInsert` are only used by code
which combines them with DartEditBuilder, so the change is pretty
simple. A few utilities are needed in DartEditBuilder, which are also
not complicated, such as a utility for getting the existing indentation
string on a line. Using this utility in the shared code should improve
someo of the existing fixes and assists, which didn't use it before.
The same goes for looking at whether left and right brackets are
synthetic. So this change comes with a few minor improvements.
Change-Id: I5b235021ac234b4a50b09dca6d14a28b3f163e5e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/360980
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Primarily this moves `prepareNewFieldLocation` and
`prepareNewGetterLocation` to DartFileEditBuilder, as
`addFieldInsertion` and `addGetterInsertion`. Where
`prepareNewFieldLocation` was previously used in conjunction with
`addInsertion`, a correction producer now just needs to call
`addFieldInsertion`. This new method determines the insertion offset,
and and prefix String and suffix String (just newlines and indents),
and handles the prefix and suffix, surrounding use of the `buildEdit`
callback.
These form a nice new API for correction producers like create_field,
create_getter, and create_setter.
The implementation is a little hairy; the DartFileEditBuilder does not
have access to things like `eol` and `getIndent`; those are made
available in DartEditBuilder, so it does that work in
`addCompilationUnitMemberInsertion`, _inside_ the call to
`addInsertion`, where that builder is available.
Though the implementation is a bit hairy, I think it is a much tidier
API for correction producers. The prior API was a little awkward in
that a correction producer would have to ask CorrectionUtils for this
odd data object that contained an offset, and a prefix and suffix
String. Rather than using these objects in any meaningful way, the
correction producer just gave it back to one or another builder. It
felt opaque to me.
The rest of the `CorrectionUtils.prepare*` methods will follow.
Change-Id: I32f23336c873cee4158a4ac6797961a40d86c25a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/360302
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This was the only caller, and it always passed in `true` for `first`.
Inlining the function is the same number of lines as calling the function and using it's output.
Change-Id: Ifee204e68f2b7d168fe6078ac7f8ec66261ff76b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/360080
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
As much as I don't like the scale of changes, there is no valid variable in these cases. So, we express this explicitly, without trying to pretend that there is on. Or crashing as we did without this CL.
Change-Id: I74cef1d3d9d3cba6985d83b98be361cca09170f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/355300
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Previously the pattern would only be recorded as a reference to the getter. If there was a reference to the declared variable elsewhere in the visited code, it would then record the variable declaration (via the reference).
In LSP, we locate declarations by only looking at the node at the cursor, so we can't rely on the declaration being recorded by some other reference (if one even exists) so this ensure it is recorded explicitly.
Fixes https://github.com/dart-lang/sdk/issues/53554.
Change-Id: I8983d0637f2d89a427fb1fa11293eec8e06fede8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326700
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The actual removal will happen in (to be rebased on top of this):
https://dart-review.googlesource.com/c/sdk/+/303280
Fixing direct uses of the deprecated `Identifier get name` is apparently
only about a half of the work. I should have followed my own advice to
the clients and prepared better.
These changes are necessary because we will stop creating and
visiting `Identifier`, and so `NamedType` should be handled directly.
Change-Id: Ie07b75b15eab277ed6c9b29a838561a7eb71f588
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/303425
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Maybe? With an explicit type check we don't try to make an impression
that anything more happens here, e.g. for type parameters.
Similarly, for https://github.com/dart-lang/sdk/issues/36697 we would need to introduce `InvalidType`, which is not `DynamicType`. And so, `DartType.isDynamic` should not return `true` for `InvalidType`, it is not a property that various types may have, and should be replaced with explicit `is DynamicType`.
We also have `UnknownInferredType`, but it should never leak to clients.
Change-Id: I302b06355143d97bb52922c805dbad585a522e0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288340
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Konstantin Shcheglov