x/tools/gopls: assembly identifier positions drift in CRLF files

[racequite]

gopls version

gopls master (x/tools@1f62bc851567)

go env

AR='ar'
CC='clang'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN='/Users/mac/go/bin'
GOCACHE='/Users/mac/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/mac/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/66/63zhln_s7wz_fn6wsbh3t2000000gn/T/go-build4005551914=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/Users/mac/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/mac/go'
GOPRIVATE=''
GOPROXY=''
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/mac/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.25.6'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

Open a Go assembly file using CRLF line endings, for example:

TEXT ·foo(SB)
	CALL ·bar(SB)

Then request Definition, References, Hover, DocumentHighlight, or another operation whose result is based on assembly identifier offsets.

What did you see happen?

Identifier positions drift left by one byte for every preceding CRLF line.
The drift also affects TEXT-based function boundaries returned by FunctionRange.

The assembly parser currently uses bufio.Scanner with bufio.ScanLines and advances the source offset using:

offset += len(scan.Bytes()) + len("\n")

ScanLines removes the trailing carriage return from CRLF tokens. Consequently, a line occupying len(line) + 2 bytes in the original file advances the parser offset by only len(line) + 1.

This affects Definition, References, Hover, DocumentHighlight, FunctionRange, and other LSP ranges derived from Ident.Offset.

What did you expect to see?

Each returned LSP range should select the corresponding identifier in the original file.

Editor and settings

No response

Logs

No response

[racequite]

Walk the original content using newline byte positions instead of deriving offsets from Scanner tokens. Strip a trailing \r only from the line passed to the parser, while retaining offsets into the original byte slice.

I would like to work on this. I plan to preserve offsets by splitting lines at newline positions in the original content, stripping CR only for parsing, and adding LF/CRLF regression coverage for identifier ranges and FunctionRange.

[gopherbot]

Change https://go.dev/cl/808480 mentions this issue: gopls/internal/util/asm: preserve offsets in CRLF files

[gabyhelp]

Related Issues

• x/tools/gopls: incorrect ending position for multiline strings on Windows (\r\n) #75969 (closed)
• x/tools/gopls: unexpected line/character calculations in certain diagnostics #40522
• go/parser: incorrect comment end position with CRLF line endings #41197 (closed)
• x/tools/gopls: comments duplicated with CRLF files #42923 (closed)
• x/tools/gopls: formatting corrupts /**/ comments with CRLF line endings #40355 (closed)
• x/tools/gopls: formatting resets cursor after save with CRLF line endings #31937 (closed)
• x/tools/gopls: FoldingRange omitempty causes EndCharacter=0 to be omitted, changing its semantics in clients that distinguish 0 from missing #71489 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}