Change-Id: Idad45a4c8352116b68eca172329214dbfb89b294
Reviewed-on: https://go-review.googlesource.com/c/tools/+/509696
Run-TryBot: shuang cui <imcusg@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Previously, the expandEdit operation would expand to
the end of the line unconditionally, but this caused it
to gulp an extra line if it was already line-aligned.
This change causes it to do the expansion only if
the end is not line-aligned, or the replacement text
doesn't end with a newline.
Now, removing the fast path no longer causes tests to fail.
This also allows us to remove the logic added in CL 489695
to work around issue golang/go#59232.
Fixesgolang/go#60379Fixesgolang/go#59232
Change-Id: Ia40e4e3bb714d75acb95103a38e8c49a8ef456de
Reviewed-on: https://go-review.googlesource.com/c/tools/+/499377
Run-TryBot: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
The fast-path "optimization" that skips the main
algorithm when the input is already line-aligned
failed to check that the replacement text consisted
of complete lines.
(Scare quotes because removing the "optimization" causes
tests to fail. See CL 499377 next in stack for why.)
Thanks to pjw for diagnosing the root cause and
providing the test case in CL 498975.
Fixesgolang/go#60379
Change-Id: I2ff92de4550754691442362b8a8932ee42971461
Reviewed-on: https://go-review.googlesource.com/c/tools/+/499376
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
Sometimes the unified diff would show the same line removed and added.
That is avoided by this CL.
Fixes: golang/go#59232
Change-Id: Ie6562e3c922b8f0c4319eefdde1913b2d9bc7878
Reviewed-on: https://go-review.googlesource.com/c/tools/+/489695
Run-TryBot: Peter Weinberger <pjw@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change adds rudimentary support for @rename
markers, which make an LSP 'rename' request and
assert that the expected file changes are obtained.
We also introduce a separate marker, @renameerr,
for expectations of failure.
The treatment both of changed files and of expected errors
should be used by other markers, for consistency.
Also:
- Env.Mapper returns an error.
- add diff.ApplyBytes and compare.Bytes convenience wrappers.
- simplify fake.ApplyEdits by using ApplyProtocolEdits.
- change ApplyProtocolEdits to use []byte.
Change-Id: Ib64b3d8e12c025f01dd0783b4faee94f082b4895
Reviewed-on: https://go-review.googlesource.com/c/tools/+/466144
Run-TryBot: Alan Donovan <adonovan@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In the removed code
if endCol := end - 1 - strings.LastIndex(src[:end], "\n"); endCol > 0
the endCol test is off by one. It should have been endCol >= 0, otherwise
there are cases where extending the edit won't be considered.
But endCol is always >= 0, as LastIndex(src[:end], "\n") is <= end-1.
Another way of saying all this is the extending the edit doesn't need
endCol at all.
The effect of this was to fail to extend edits if the edit started
the line.
The tests were revised to check unified diffs by using the
patch command.
Fixes: golang/go#457256
Change-Id: Idb23f1a28d36f92a7b8712e9459df86a3d420d7e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/459236
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Peter Weinberger <pjw@google.com>
The LSP protocol doesn't require edits to be sorted,
but some clients such as govim were relying on it,
as we learned when I recently removed the sort.
This change restores the sort behavior.
See also govim/govim#1171
Change-Id: I589b6cfde933ea6907859bf40acd33c1a7fcde02
Reviewed-on: https://go-review.googlesource.com/c/tools/+/442256
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
LineEdits has similar consistency preconditions to ApplyEdits.
Previously they were assumed, and bad input would create bad
output or crashes; now it uses the same validation logic
as ApplyEdits. Since it reports an error, computation of a
unified diff can also fail if the edits are inconsistent.
The ToUnified([]Edit) function now returns an error. For
convenience we also provide a wrapper (Unified) that cannot
fail since it calls Strings and ToUnified consistently.
LineEdits itself is now private.
Change-Id: I3780827f501d7d5c9665ec8be5656331c0dcda8e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/440175
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Alan Donovan <adonovan@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Previously, a diff of non-ASCII strings would incur
three complete copies of the buffers; this changes
reduces it to one.
Also:
- add diff.Bytes function, to avoid unnecessary conversions.
- remove unused diff.Lines and LineEdits functions from API.
- remove TODO to use []bytes everywhere.
We tried it in CL 439277 and didn't like it.
- Document that the diff is textual, even when given []byte.
Change-Id: I2da3257cc3d12c569218a2d7ce182452e8647a96
Reviewed-on: https://go-review.googlesource.com/c/tools/+/439835
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Apply now checks that its edits are valid
(not out of bounds or overlapping),
and reports an error if not.
It also sorts them, if necessary, using (start, end)
as the key, to ensure that insertions (end=start)
are ordered before deletions at the same point
(but without changing the relative order of insertions).
Two other implementations of the diff.Apply algorithm
have been eliminated. (One of them failed to sort edits,
requiring the protocol sender to do so; that burden
is now gone.)
Change-Id: Ia76e485e6869db4a165835c3312fd14bc7d43db2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/439278
Auto-Submit: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
diff.TextEdit (now called simply Edit) no longer has a Span,
and no longer depends on the span package, which is really
part of gopls. Instead, it records only start/end byte
offsets within an (implied) file.
The diff algorithms have been simplified to avoid the need to
map offsets to line/column numbers (e.g. using a token.File).
All the conditions actually needed by the logic can be derived
by local string operations on the source text.
This change will allow us to move the span package into the
gopls module.
I was expecting that gopls would want to define its own
Span-augmented TextEdit type but, surprisingly, diff.Edit
is quite convenient to use throughout the entire repo:
in all places in gopls that manipulate Edits, the implied
file is obvious. In most cases, less conversion boilerplate
is required than before.
API Notes:
- diff.TextEdit -> Edit (it needn't be text)
- diff.ApplyEdits -> Apply
- source.protocolEditsFromSource is now private
Change-Id: I4d7cef078dfbd189b4aef477f845db320af6c5f6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/436781
Run-TryBot: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Computing the difference between two strings is logically an
infallible operation. This change makes the code reflect that. The
actual failures were unreachable given consistent inputs, but that was
hard to see from the complexity of the logic surrounding span.Span.
(The problem only occurs when converting offsets beyond the end of the
file to Spans, but the code preserves the integrity of offsets.)
gopls' "old" hooks.ComputeEdits impl (based on sergi/go-diff) now
reports a bug and returns a single diff for the entire file if it
panics.
Also, first steps towards simpler API and a
reusable diff package in x/tools:
- add TODO for new API. In particular, the diff package shouldn't care
about filenames, spans, and URIs. These are gopls concerns.
- diff.String is the main diff function.
- diff.Unified prints edits in unified form;
all its internals are now hidden.
- the ComputeEdits func type is moved to gopls (source.DiffFunction)
- remove all non-critical uses of myers.ComputeEdits. The only
remaining one is in gopls' defaults, but perhaps that gets
overridden by the default GoDiff setting in hooks, to BothDiffs
(sergi + pjw impls), so maybe it's now actually unused in practice?
Change-Id: I6ceb5c670897abbf285b243530a7372dfa41edf6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/436778
Run-TryBot: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
This CL was created using the following commands:
./gopls/internal/migrate.sh
git add .
git codereview gofmt
For golang/go#54509
Change-Id: Iceeec602748a5e6f609c3ceda8d19157e5c94009
Reviewed-on: https://go-review.googlesource.com/c/tools/+/426796
gopls-CI: kokoro <noreply+kokoro@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Peter Weinberger <pjw@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
cui fliter
Alan Donovan
Peter Weinberger
Robert Findley