search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
123.99k stars 17.67k forks source link

x/tools/gopls: incorrect completion ranges for multi-byte character at the end of a document #45883

Open mattmassicotte opened 3 years ago

mattmassicotte commented 3 years ago

What version of Go are you using (go version)?

go version go1.16.3 darwin/arm64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

GOHOSTARCH="arm64" GOHOSTOS="darwin"

(however, I'm running gopls built for amd64)

What did you do?

Request completions with gopls at the very end of a document which as a last line of:

}Å

Note that there is no newline at the end.

What did you expect to see?

I expected to get completions referencing a location of 2 on this line

What did you see instead?

Got back completions with locations of 3

This looks like a potential latent character encoding issue, but because these kinds of things are really tricky to work out, so it could end up being an issue on my end. However, I am consistently getting back what I believe are invalid character ranges when a multi-byte (but still single UTF16) character is at the very end of the document. Figured it was worth a report.

cherrymui commented 3 years ago

cc @stamblerre @suzmue

suzmue commented 3 years ago

Thanks for filing this issue! This is a somewhat tricky problem. Is this causing you a lot of trouble?

mattmassicotte commented 3 years ago

Thank you for responding to it so quickly! It was causing me a little grief, because I was using very strict range validation for my application. I would prefer to keep it that way, especially since this is quite the edge-case. Please don't feel pressure to prioritize this any more highly because of my report.

Can I ask, is this only an issue for the last character, or could this come up in other situations too?

findleyr commented 3 years ago

This is only an issue for the last character: many of our internal functions don't differentiate between newline-terminated and non-newline-terminated files, so fixing this would require some non-trivial refactoring.

I don't think we can prioritize this now, but we should address it at some point. Thank you for reporting.

hyangah commented 3 years ago

@gopherbot remove label Documentation