Copying change builders in order to enable reverting changes from a
single correction producer when there's an exception is expensive.
This CL replaces that implementation with a transactional model.
Clients are not required to start a transaction (that happens
automatically), but are required to signal the end of a transaction by
invoking either `commit` or `revert`. (Actually, `commit` is assumed
if neither method is invoked before computing the `SourceChange`.)
There is some information in the Dart file edit builder related to
imports that isn't correctly handled. The reason for this is that too
much of the import computation is done up-front. I don't think this
will be a problem in practice (or at least not often), but we should
come back at some point to change the implementation so that we retain
abstract data longer and perform more processing at the very end (where
we'll have complete information and probably be able to do a better
job anyway).
This CL improved the performance of the benchmark that adds and applies
fixes for 10,000 lint violations.
Before it took an average of 11216.0 ms.
After it took an average of 4200.2 ms.
Which is about a 62% improvement.
Change-Id: I12710606455a04e34a82308ede5d9fba1c68b972
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428060
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
There was a mix of the term "field formal" and "initializing formal" in fixes and assists. This changes those that used "field formal" to "initializing formal" (which seems to be the term used most here and on the website).
I did not update all places that use this (for example there are many in the analyzer, including classes).
Change-Id: Ia4a1095a756adb35ca7faa8dc06c541abb04bfcc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/413781
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
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>
FMorschel