aboutsummaryrefslogtreecommitdiff
path: root/src/time/time_test.go
diff options
context:
space:
mode:
authorRobert Griesemer <gri@golang.org>2022-04-25 16:26:10 -0700
committerGopher Robot <gobot@golang.org>2022-04-26 02:19:42 +0000
commit09ada1af8f54584e46deb0d643713393a9d83b10 (patch)
tree8589fdc5ac30ebdbe3ad4d1432462ee3925a1024 /src/time/time_test.go
parente845750744b648b8b348bbcebe2ff85d4e6247c5 (diff)
downloadgo-09ada1af8f54584e46deb0d643713393a9d83b10.tar.gz
go-09ada1af8f54584e46deb0d643713393a9d83b10.zip
cmd/compile/internal/syntax: parser to accept ~x as unary expression
Accept ~x as ordinary unary expression in the parser but recognize such expressions as invalid in the type checker. This change opens the door to recognizing complex type constraint literals such as `*E|~int` in `[P *E|~int]` and parse them correctly instead of reporting a parse error because `P*E|~int` syntactically looks like an incorrect array length expression (binary expression where the RHS of | is an invalid unary expression ~int). As a result, the parser is more forgiving with expressions but the type checker will reject invalid uses as before. We could pass extra information into the binary/unary expression parse functions to prevent the use of ~ in invalid situations but it doesn't seem worth the trouble. In fact it may be advantageous to allow a more liberal expression syntax especially in the presence of errors (better parser synchronization after an error). Preparation for fixing #49482. Change-Id: I119e8bd9445dfa6460fcd7e0658e3554a34b2769 Reviewed-on: https://go-review.googlesource.com/c/go/+/402255 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com>
Diffstat (limited to 'src/time/time_test.go')
0 files changed, 0 insertions, 0 deletions