Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

regexp: LiteralPrefix returns surprising result for ^ anchored strings #33506

Open
eliben opened this issue Aug 6, 2019 · 3 comments
Open

regexp: LiteralPrefix returns surprising result for ^ anchored strings #33506

eliben opened this issue Aug 6, 2019 · 3 comments
Labels
NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Backlog

Comments

@eliben
Copy link
Member

eliben commented Aug 6, 2019

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

$ go version
go version go1.12.5 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/usr/local/google/home/eliben/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/usr/local/google/home/eliben/go"
GOPROXY="https://proxy.golang.org"
GORACE=""
GOROOT="/usr/lib/google-golang"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/google-golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build346731385=/tmp/go-build -gno-record-gcc-switches"

What did you do?

package main

import (
	"fmt"
	"regexp"
)

func main() {
	for _, p := range []string{"foo", "^foo"} {
		prefix, _ := regexp.MustCompile(p).LiteralPrefix()
		fmt.Printf("prefix = '%v'\n", prefix)
	}
}

What did you expect to see?

The documentation for LiteralPrefix says:

LiteralPrefix returns a literal string that must begin any match of the regular expression re. It returns the boolean true if the literal string comprises the entire regular expression.

So I expected to see "foo" in both cases, since every any match of the regular expression ^foo begins with the literal "foo".

prefix = 'foo'
prefix = 'foo'

What did you see instead?

prefix = 'foo'
prefix = ''

In #21463 (comment), @rsc says:

"It looks like the literal prefix matcher doesn't kick in for anchored patterns, and we should fix that.

Also, see discussion in #30425
@odeke-em odeke-em added the NeedsFix The path to resolution is known, but the work has not been done. label Aug 11, 2019
@rsc
Copy link
Contributor

rsc commented Sep 26, 2019

I don't understand how this issue differs from #30425.

@eliben
Copy link
Member Author

eliben commented Sep 27, 2019 •
edited

I opened a separate issue because I wanted to restrict the discussion in #30425 only to the change in behavior between Go versions and what to do about that.

This issue questions the documented semantics of LiteralPrefix in general, compared to its actual behavior. Your new comment says that the 1.2 behavior is the correct one, which sounds logical. However, this means:

"^foo" : prefix="" complete=false

While the documentation of LiteralPrefix says:

LiteralPrefix returns a literal string that must begin any match of the regular expression re. It returns the boolean true if the literal string comprises the entire regular expression.

Any match of "^foo" must begin with foo, so on the face of it, the returned prefix="" seems surprising. Would you disagree?

We could update the comment on LiteralPrefix to make the distinction for anchored regexes, which would bring it in line with the actual behavior. Or we could make LiteralPrefix return foo for "^foo", but complete=false.

If you prefer to discuss everything in #30425, no problem, I can close this issue.

@gopherbot
Copy link

Change https://golang.org/cl/377294 mentions this issue: regexp: allow prefix string anchored at beginning

@seankhliao seankhliao added this to the Backlog milestone Aug 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
5 participants
@rsc @eliben @odeke-em @gopherbot @seankhliao