delta/go-git.git/src/regexp/syntax, branch dev.boringcrypto

regexp/syntax: rename ErrInvalidDepth to ErrNestingDepth

2022-04-22T22:35:03+00:00

The proposal accepted the name ErrNestingDepth.

For #51684

Change-Id: I702365f19e5e1889dbcc3c971eecff68e0b08727
Reviewed-on: https://go-review.googlesource.com/c/go/+/401854
Run-TryBot: Ian Lance Taylor 
Reviewed-by: Ian Lance Taylor 
Run-TryBot: Ian Lance Taylor 
Auto-Submit: Ian Lance Taylor 
TryBot-Result: Gopher Robot 
Reviewed-by: Rob Pike 
Reviewed-by: Dmitri Shuralyov

regexp: change ErrInvalidDepth message to match proposal

2022-04-22T00:10:17+00:00

Also update the file in $GOROOT/api/next to use proposal number.

For #51684

Change-Id: I28bfa6bc1cee98a17b13da196d41cda34d968bb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/401076
Reviewed-by: Rob Pike 
Reviewed-by: Ian Lance Taylor 
Run-TryBot: Ian Lance Taylor 
Auto-Submit: Ian Lance Taylor 
TryBot-Result: Gopher Robot 
Reviewed-by: Dmitri Shuralyov

all: gofmt main repo

2022-04-11T16:34:30+00:00

[This CL is part of a sequence implementing the proposal #51082.
The design doc is at https://go.dev/s/godocfmt-design.]

Run the updated gofmt, which reformats doc comments,
on the main repository. Vendored files are excluded.

For #51082.

Change-Id: I7332f099b60f716295fb34719c98c04eb1a85407
Reviewed-on: https://go-review.googlesource.com/c/go/+/384268
Reviewed-by: Jonathan Amsterdam 
Reviewed-by: Ian Lance Taylor

all: replace `` and '' with “ (U+201C) and ” (U+201D) in doc comments

2022-04-05T17:52:29+00:00

go/doc in all its forms applies this replacement when rendering
the comments. We are considering formatting doc comments,
including doing this replacement as part of the formatting.
Apply it to our source files ahead of time.

For #51082.

Change-Id: Ifcc1f5861abb57c5d14e7d8c2102dfb31b7a3a19
Reviewed-on: https://go-review.googlesource.com/c/go/+/384262
Trust: Russ Cox 
Run-TryBot: Russ Cox 
TryBot-Result: Gopher Robot 
Reviewed-by: Ian Lance Taylor

regexp/syntax: add and use ErrInvalidDepth

2022-04-04T10:59:27+00:00

The fix for #51112 introduced a depth check but used
ErrInternalError to avoid introduce new API in a CL that
would be backported to earlier releases.

New API accepted in proposal #51684.

This CL adds a distinct error for this case.

For #51112.
Fixes #51684.

Change-Id: I068fc70aafe4218386a06103d9b7c847fb7ffa65
Reviewed-on: https://go-review.googlesource.com/c/go/+/384617
Trust: Russ Cox 
Run-TryBot: Russ Cox 
Reviewed-by: Ian Lance Taylor 
TryBot-Result: Gopher Robot

all: remove trailing blank doc comment lines

2022-04-01T18:18:07+00:00

A future change to gofmt will rewrite

	// Doc comment.
	//
	func f()

to

	// Doc comment.
	func f()

Apply that change preemptively to all doc comments.

For #51082.

Change-Id: I4023e16cfb0729b64a8590f071cd92f17343081d
Reviewed-on: https://go-review.googlesource.com/c/go/+/384259
Trust: Russ Cox 
Run-TryBot: Russ Cox 
Reviewed-by: Ian Lance Taylor 
TryBot-Result: Gopher Robot

regexp/syntax: reject very deeply nested regexps in Parse

2022-02-10T15:23:05+00:00

The regexp code assumes it can recurse over the structure of
a regexp safely. Go's growable stacks make that reasonable
for all plausible regexps, but implausible ones can reach the
“infinite recursion?” stack limit.

This CL limits the depth of any parsed regexp to 1000.
That is, the depth of the parse tree is required to be ≤ 1000.
Regexps that require deeper parse trees will return ErrInternalError.
A future CL will change the error to ErrInvalidDepth,
but using ErrInternalError for now avoids introducing new API
in point releases when this is backported.

Fixes #51112.

Change-Id: I97d2cd82195946eb43a4ea8561f5b95f91fb14c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/384616
Trust: Russ Cox 
Run-TryBot: Russ Cox 
Reviewed-by: Ian Lance Taylor

regexp: document and implement that invalid UTF-8 bytes are the same as U+FFFD

2021-10-11T15:28:50+00:00

What should it mean to run a regexp match on invalid UTF-8 bytes?
The coherent behavior options are:

1. Invalid UTF-8 does not match any character classes,
   nor a U+FFFD literal (nor \x{fffd}).
2. Each byte of invalid UTF-8 is treated identically to a U+FFFD in the input,
   as a utf8.DecodeRune loop might.

RE2 uses Rule 1.
Because it works byte at a time, it can also provide \C to match any
single byte of input, which matches invalid UTF-8 as well.
This provides the nice property that a match for a regexp without \C
is guaranteed to be valid UTF-8.

Unfortunately, today Go has an incoherent mix of these two, although
mostly Rule 2. This is a deviation from RE2, and it gives up the nice
property, but we probably can't correct that at this point.
In particular .* already matches entire inputs today, valid UTF-8 or
not, and I doubt we can break that.

This CL adopts Rule 2 officially, fixing the few places that deviate from it.

Fixes #48749.

Change-Id: I96402527c5dfb1146212f568ffa09dde91d71244
Reviewed-on: https://go-review.googlesource.com/c/go/+/354569
Trust: Russ Cox 
Run-TryBot: Russ Cox 
TryBot-Result: Go Bot 
Reviewed-by: Rob Pike

all: use bytes.Cut, strings.Cut

2021-10-06T15:53:04+00:00

Many uses of Index/IndexByte/IndexRune/Split/SplitN
can be written more clearly using the new Cut functions.
Do that. Also rewrite to other functions if that's clearer.

For #46336.

Change-Id: I68d024716ace41a57a8bf74455c62279bde0f448
Reviewed-on: https://go-review.googlesource.com/c/go/+/351711
Trust: Russ Cox 
Run-TryBot: Russ Cox 
TryBot-Result: Go Bot 
Reviewed-by: Ian Lance Taylor

regexp: fix repeat of preferred empty match

2021-05-13T14:52:20+00:00

In Perl mode, (|a)* should match an empty string at the start of the
input. Instead it matches as many a's as possible.
Because (|a)+ is handled correctly, matching only an empty string,
this leads to the paradox that e* can match more text than e+
(for e = (|a)) and that e+ is sometimes different from ee*.

This is a very old bug that ultimately derives from the picture I drew
for e* in https://swtch.com/~rsc/regexp/regexp1.html. The picture is
correct for longest-match (POSIX) regexps but subtly wrong for
preferred-match (Perl) regexps in the case where e has a preferred
empty match. Pointed out by Andrew Gallant in private mail.

The current code treats e* and e+ as the same structure, with
different entry points. In the case of e* the preference list ends up
not quite in the right order, in part because the “before e” and
“after e” states are the same state. Splitting them apart fixes the
preference list, and that can be done by compiling e* as if it were
(e+)?.

Like with any bug fix, there is a very low chance of breaking a
program that accidentally depends on the buggy behavior.

RE2, Go, and Rust all have this bug, and we've all agreed to fix it,
to keep the implementations in sync.

Fixes #46123.

Change-Id: I70e742e71e0a23b626593b16ddef3c1e73b413b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/318750
Trust: Russ Cox 
Run-TryBot: Russ Cox 
Reviewed-by: Rob Pike 
TryBot-Result: Go Bot