regexp/syntax: [a-y] parses as [a-z] with (?i)

[rgmz]

Go version

go version go1.24.2 linux/amd64

Output of go env in your module/workspace:

`go env` output

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE='on'
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/me/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/me/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3280803028=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/me/dev/github.com/gitleaks/gitleaks/go.mod'
GOMODCACHE='/home/me/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/rich/go'
GOPRIVATE=''
GOPROXY='direct'
GOROOT='/usr/lib/golang'
GOSUMDB='off'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/me/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/lib/golang/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.24.2'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

I was writing test cases to detect "strange" character class ranges (i.e., a user does =-_ and inadvertently creates a range). It appears there is a bug with how syntax.Parse handles character ranges in conjunction with (?i).

https://go.dev/play/p/2p8l3zJi-4T

Note: [a-x] reference in the title refers to any range other than a-z.

What did you see happen?

The pattern (?i)[a-l0-9=-_] is parsed as a-z and not a-l as expected.

Pattern is: [0-9=-_a-zſK]
Pattern is: [0-9=A-L_a-lK]
Pattern is: [0-9=-_a-l]
Pattern is: [0-9=A-L_a-l]

What did you expect to see?

All patterns are printed as [a-l].

Pattern is: [0-9=-_a-lſK]
Pattern is: [0-9=A-L_a-lK]
Pattern is: [0-9=-_a-l]
Pattern is: [0-9=A-L_a-l]

[gabyhelp]

Related Issues

• regexp: compiling incorrectly #59007
• path,path/filepath: clarify that patterns don't conform to the POSIX Shell spec #23456 (closed)

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

[Hiworle]

This may not be a bug. In the first example, (?i)[a-l0-9=-_] is parsed as [0-9=-_a-zſK] because in ASCII encoding, = (61) and _ (95) happen to include A (65)-Z (90) (in JS, /[0-9=-_a-z]/i.test('z') also returns true). You might replace - with \- to get the correct result:
https://go.dev/play/p/761NDru9plV

[rgmz]

This may not be a bug. In the first example, (?i)[a-l0-9=-_] is parsed as [0-9=-_a-zſK] because in ASCII encoding, = (61) and _ (95) happen to include A (65)-Z (90) (in JS, /[0-9=-_a-z]/i.test('z') also returns true).

I considered that. I'd expect [a-l0-9=-_] (no (?i)) to behave similarly, yet it exhibits different behaviour.

You might replace - with \- to get the correct result: https://go.dev/play/p/761NDru9plV

- is important for the context of the issue.

[Hiworle]

The difference is whether it includes l-z.

[rgmz]

The difference is whether it includes l-z.

I don't follow.

It seems unexpected that (?i)[a-l0-9=-_] => [0-9=-_a-zſK] and [a-lA-L0-9=-_] => [0-9=-_a-l] produce different outputs — ignoring the ſK symbols added for case folding.

[adonovan]

Consider the minimal example(?i)[=-_]. The last three chars are not literals--the middle one is a metacharacter--so the whole is parsed as a range of the form p-q. In this case, = U+003D is the start and _ U+005F is the end. That interval includes the uppercase ASCII letters A-Z. So, the case folding of (?i) augments the pattern to include a-zſK as well.

It may be confusing that without (?i), the pattern is printed as just [=-_], making the interval (which includes A-Z) hard to see. But I think it is working as intended.

[JunyangShao]

@rgmz Does Alan's comment answer your question? If it's WAI feel free to close this issue, thank you 👍
@matloob

[rgmz]

Thanks for your insights, @adonovan!