Update: I read the perldelta wrong: unescaped left-brace is only deprecated in 5.24. It will become fatal in 5.26 (which is expected out soon, within a few months). So, currently, this bug will only show up for folks running Perls from the 5.25.x development releases.

The actual use of perl is in the script test/errchk.

@ianlancetaylor, we have a Go version of errchk already in test/run.go. (hence my longer title about one view of the bug being that we depend on Perl)

That said, it might be just changing:

    $regexp = "$`$file:$n$'";

to:

    $regexp = "\\Q$`\\E$file:$n$'";

(or quotameta)

Sorry, our subject line editing collided. I never saw yours.

Quite frankly, this entire test suite is confused whether the error lines it's dealing with are plain strings or regexes.

This particular error is caused by this line. This is clearly meant to be matched stringwise, as are many other strings (that work fine most of the time because the meta-character . matches itself as literal character .).

Do you really need these to be regexes? If not I would recommend just quotemeta()ing it early (this may involve unquoting a few cases that are currently hand-quoted, for example because they contain a *).

If you do need it, I would recommend consistently quoting all error strings.

One possible intermediate solution is to add a new syntax that will explicitly enable the regular expression syntax. Something like:

  foo(1) // ERROR /some \d+ regexp/

All of this you really want to fix regardless of what perl is doing.

In general the ERROR lines that appear in the files in the test directory are always intended to be regular expressions. I am less familiar with the use in vet, but if vet wants to match the way that the test directory works then the ERROR lines there should also always be regexps. Thanks for identifying the line; probably the right solution is to backslash-quote the . characters.

Thanks for identifying the line; probably the right solution is to backslash-quote the . characters.

The primary problem here isn't the . characters, but the {s

My attempts to install a dev version of perl failed. Can someone confirm that CL 40950 fixes the immediate problem? Thanks.

Here's a Debian jessie environment with Perl 5.25. You can build it and docker run it with some -v flags to bind mount your $GOROOT and $GOROOT_BOOTSTRAP to reproduce.

FROM buildpack-deps
MAINTAINER Peter Martini <PeterCMartini@GMail.com>

RUN apt-get update \
    && apt-get install -y curl procps \
        && rm -fr /var/lib/apt/lists/*

RUN mkdir /usr/src/perl
WORKDIR /usr/src/perl

RUN curl -SL https://cpan.metacpan.org/authors/id/S/SH/SHAY/perl-5.25.3.tar.bz2 -o perl-5.25.3.tar.bz2 \
        && tar --strip-components=1 -xjf perl-5.25.3.tar.bz2 -C /usr/src/perl \
            && rm perl-5.25.3.tar.bz2 \
                    && ./Configure -Duse64bitall -Duseshrplib -Dusedevel  -des \
                        && make -j$(nproc) \
                            && TEST_JOBS=$(nproc) make test_harness \
                                && make install \
                                    && cd /usr/src \
                                        && curl -LO https://raw.githubusercontent.com/miyagawa/cpanminus/master/cpanm \
                                            && chmod +x cpanm \
                                                && ./cpanm App::cpanminus \
                                                    && rm -fr ./cpanm /root/.cpanm /usr/src/perl /tmp/*

WORKDIR /root

FYI Latest go18 (go1.8.4-0-gf5bcb9b8fe) fails to bootstrap on Debian 9 because of this bug:

ok      cmd/vendor/golang.org/x/arch/x86/x86asm 0.140s
--- FAIL: TestVet (0.84s)
    --- FAIL: TestVet/1 (0.06s)
        vet_test.go:114: files: ["testdata/atomic.go" "testdata/copylock_func.go" "testdata/lostcancel.go" "testdata/rangeloop.go" "testdata/unsafeptr.go"]
        vet_test.go:163: vet output:
                Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/call of f copies lock value: struct{ <-- HERE lock sync.Mutex} contains sync.Mutex/ at /home/kirr/src/tools/go/go18/test/errchk line 128.
        vet_test.go:164: exit status 1
FAIL
FAIL    cmd/vet 1.581s

Go18 should be still supported according to release poilcy, thus it is better to backport 2e45310 there.

Latest Go14 bootstraps ok.

FYI Latest go18 (go1.8.4-0-gf5bcb9b8fe) fails to bootstrap on Debian 9 because of this bug:
...

@rsc you probably overlooked this while backporting patches to go1.8.5