Generally, the parser strips (i.e., does not record in the syntax tree)
unnecessary parentheses. Specifically, given a type parameter list of
the form
[P (C),]
it records it as
[P C]
and then no comma is required when printing. However it did only strip
one level of parentheses, and
[P ((C)),]
made it through, causing a panic when printing. Somewhat related,
the printer stripped parentheses around constraints as well.
This CL implements a more consistent behavior:
1) The parser strips all parentheses around constraints. For testing
purposes, a local flag (keep_parens) can be set to retain the
parentheses.
2) The printer code now correctly intruces a comma if parentheses
are present (e.g., when testing with keep_parens). This case does
not occur in normal operation.
3) The printer does not strip parentheses around constraints since
the parser does it already.
For #69206.
Change-Id: I974a800265625e8daf9477faa9ee4dd74dbd17ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/610758
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
CL 594740 rewrote type checking of method receiver types. Because that
CL takes apart receivers "manually" rather than using the regular code
for type checking type expressions, pointer and parenthesized receiver
type expressions were not recorded anymore.
Adjust the code that typechecks method receivers to a) use ordinary
type expression checking for non-generic receivers, and b) to record
a missing pointer and any intermediate parenthesized expressions in
case of a generic receiver.
Add many extra tests verifying that the correct types for parenthesized
and pointer type expressions are recorded in various source positions.
Note that the parser used by the compiler and types2 doesn't encode
unnecessary parentheses in type expressions in its syntax tree.
As a result, the tests that explicitly test parentheses don't work
in types2 and are commented out.
This CL adds code (disabled by default) to the parser to encode
parentheses in type expressions in the syntax tree. When enabled,
the commented out types2 tests pass like in go/types.
Fixes#68639.
For #51343.
Change-Id: Icf3d6c76f7540ee53e229660be8d78bb25380539
Reviewed-on: https://go-review.googlesource.com/c/go/+/601657
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In an attempt to address issue #65790 (confusing error messages),
quoting of names was introduced for some (but not all) names used
in error messages.
That CL solved the issue at hand at the cost of extra punctuation
(the quotes) plus some inconsistency (not all names were quoted).
This CL removes the quoting again in favor or adding a qualifying noun
(such as "name", "label", "package", "built-in" etc.) before a user-
specified name where needed.
For instance, instead of
invalid argument to `max'
we now say
invalid argument to built-in max
There's still a chance for confusion. For instance, before an error
might have been
`sadly' not exported by package X
and now it would be
name sadly not exported by package X
but adverbs (such as "sadly") seem unlikely names in programs.
This change touches a lot of files but only affects error messages.
Fixes#67685.
Change-Id: I95435b388f92cade316e2844d59ecf6953b178bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/589118
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Use quotes to wrap user-supplied token in the syntax error message.
Updates #65790
Change-Id: I631a63df4a6bb8615b7850a324d812190bc15f30
GitHub-Last-Rev: f291e1d5a6adee558d21bb7e0a3a17471bad7eb6
GitHub-Pull-Request: golang/go#65840
Reviewed-on: https://go-review.googlesource.com/c/go/+/565518
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This is a port of CL 538856 from the syntax parser to go/parser.
As part of the port, make more portions of parseParameterList
matching the equivalent paramList method (from the syntax parser).
As a result, this now also produces a better error message in cases
where the missing piece might not be a type parameter name but a
constraint (this fixes a TODO in a test).
Improve comments in the code and adjust the corresponding comments
in the syntax parser.
Change references to issues to use the format go.dev/issue/ddddd.
For #60812.
Change-Id: Ia243bd78161ed8543d3dc5deb20ca4a215c5b1e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/538858
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When parsing a declaration of the form
type a [b[c]]d
where a, b, c, d stand for identifiers, b[c] is parsed as a type
constraint (because an array length must be constant and an index
expression b[c] is never constant, even if b is a constant string
and c a constant index - this is crucial for disambiguation of the
various possibilities).
As a result, the error message referred to a missing type parameter
name and not an invalid array declaration.
Recognize this special case and report both possibilities (because
we can't be sure without type information) with the new error:
"missing type parameter name or invalid array length"
ALso, change the previous error message
"type parameter must be named"
to
"missing type parameter name"
which is more fitting as the error refers to an absent type parameter
(rather than a type parameter that's somehow invisibly present but
unnamed).
Fixes#60812.
Change-Id: Iaad3b3a9aeff9dfe2184779f3d799f16c7500b34
Reviewed-on: https://go-review.googlesource.com/c/go/+/538856
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
We do the same elsewhere (e.g. in parser.name when a name is missing).
This ensures functions have a (dummy) name and a non-nil type.
Avoids a crash in the type-checker (verified manually).
A test was added here (rather than the type checker) because type-
checker tests are shared between types2 and go/types and error
recovery in this case is different.
Fixes#63835.
Change-Id: I1460fc88d23d80b8d8c181c774d6b0a56ca06317
Reviewed-on: https://go-review.googlesource.com/c/go/+/538059
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Previously, strings.LastIndexByte couldn't be used because it was only
added in Go 1.5 but Go 1.4 was required for bootstrapping. In Go 1.18,
the bootstrap toolchain was bumped to Go 1.17 (see #44505), thus
strings.LastIndexByte can be used now.
Change-Id: I01a70a59dbfc853cf03d49747a2dd62d21ba74e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/522197
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
We've added Unparen to go/ast, so add syntax.Unparen to be
consistent (and because it's similarly useful).
Also, types2 and noder both have similar functions for unpacking
ListExprs, so might as well add a common implementation in package
syntax too.
Finally, addressing the TODO: UnpackListExpr is small enough to be
inlined (when default optimizations are enabled), and for typical uses
of UnpackListExpr (e.g., "range UnpackListExpr(x)") the single-element
slice result is stack allocated in the caller. This CL adds a test
using testing.AllocsPerRun to ensure this remains so in the future.
Change-Id: I96a5591d202193ed5bf1ce6f290919107e3dc01b
Reviewed-on: https://go-review.googlesource.com/c/go/+/522336
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
When = is used instead of == as part of a conditional expression,
the parser message emphasizes the LHS and RHS of = by always
parenthesizing the two sides. For example, for:
if x = y {}
the error is:
cannot use assignment (x) = (y) as value
This is done to highlight the LHS and RHS in case of more complex
cases such as
if x || y = z {}
which one may incorrectly read as (x) || (y == z) rather than the
correct (x || y) = z.
This CL fine-tunes the error message a bit by only adding the
parentheses if the LHS and RHS are binary expressions.
Fixes#60599.
For #23385.
Change-Id: Ida4c8d12464cc2ac15c934f24858eb6f43cf9950
Reviewed-on: https://go-review.googlesource.com/c/go/+/500975
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #57001, compilers and others tools will need to understand that
a different Go version can be used in different files in a program,
according to the //go:build lines in those files.
Update go/parser to populate the new ast.File.GoVersion field.
This requires running the go/scanner in ParseComments mode
always and then implementing discarding of comments in the
parser instead of the scanner. The same work is done either way,
since the scanner was already preparing the comment result
and then looping. The loop has just moved into go/parser.
Also make the same changes to cmd/compile/internal/syntax,
both because they're necessary and to keep in sync with go/parser.
For #59033.
Change-Id: I7b867f5f9aaaccdca94af146b061d16d9a3fd07f
Reviewed-on: https://go-review.googlesource.com/c/go/+/476277
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Change-Id: I4cff6b2a1fed6acdf754539c3c53a61eaa3b3f84
Reviewed-on: https://go-review.googlesource.com/c/go/+/450176
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also make error recovery slightly more robust in this case.
Fixes#56022.
Change-Id: I1c01c1465adb48c71367d037b6f0e3fe56f68ec9
Reviewed-on: https://go-review.googlesource.com/c/go/+/438540
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Report a syntax error if the first element of a type instance is
not actually a type (but some other expression), rather then relying
on the type checker error in this case. This matches the behavior of
go/parser. Adjust the corresponding types2 test case.
For #54511.
Change-Id: Ia82b3a7d444738c56955ce6c15609470b3431fd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/426657
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Instead of checking at parse-time that the LHS of a short variable
declaration contains only identifiers, leave the check to the the
type checker which tests this already.
This removes a duplicate error and matches the behavior of the
syntax package.
For #54511.
Change-Id: I4c68f2bd8a0e015133685f9308beb98e714a83fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/426476
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
The syntax for go and defer specifies an arbitrary expression, not
a call; the call requirement is spelled out in prose. Don't to the
call check in the parser; instead move it to the type checker. This
is simpler and also allows the type checker to check expressions that
are not calls, and avoid "not used" errors due to such expressions.
We would like to make the same change in go/parser and go/types
but the change requires Go/DeferStmt nodes to hold an ast.Expr
rather than an *ast.CallExpr. We cannot change that for backward-
compatibility reasons. Since we don't test this behavior for the
type checkers alone (only for the compiler), we get away with it
for now.
Follow-up on CL 425675 which introduced the extra errors in the
first place.
Change-Id: I90890b3079d249bdeeb76d5673246ba44bec1a7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/425794
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
- Use "expected X" rather then "expecting X".
- Report a better error when a type argument list is expected.
- Adjust various tests.
For #54511.
Change-Id: I0c5ca66ecbbdcae1a8f67377682aae6b0b6ab89a
Reviewed-on: https://go-review.googlesource.com/c/go/+/425734
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
If the go/defer syntax is bad, using a fake CallExpr may produce
a follow-on error in the type checker. Instead store a BadExpr
in the syntax tree (since an error has already been reported).
Adjust various tests.
For #54511.
Change-Id: Ib2d25f8eab7d5745275188d83d11620cad6ef47c
Reviewed-on: https://go-review.googlesource.com/c/go/+/425675
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Instead of simply reporting an error but otherwise dropping the
index expression from the parse tree when an index is missing
(as in: x[]), create an index expression with a "bad expression"
as index. This matches the behavior of go/parser and permits the
use of the same test case for both parsers.
(It would be simpler to adjust the go/parser to match the syntax
parser's behavior, but that would break backward-compatibility
of the go/parser.)
Adjust the affected test files.
For #54511.
Change-Id: If7668973794604593e869a24b560da92e100b812
Reviewed-on: https://go-review.googlesource.com/c/go/+/424654
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Type parameter lists starting with the form [name *T|...] or
[name (X)|...] may look like an array length expression [x].
Only after parsing the entire initial expression and checking
whether the expression contains type elements or is followed
by a comma can we make the final decision.
This change simplifies the existing parsing strategy: instead
of trying to make an upfront decision with limited information
(which is insufficient), the parser now parses the start of a
type parameter list or array length specification as expression.
In a second step, if the expression can be split into a name
followed by a type element, or a name followed by an ordinary
expression which is succeeded by a comma, we assume a type
parameter list (because it can't be an array length).
In all other cases we assume an array length specification.
Fixes#49482.
Change-Id: I269b6291999bf60dc697d33d24a5635f01e065b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/402256
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
When we have an error in a function type used in an expression
we don't know until we see an opening { whether we have a function
literal or a function type. Use "function type" as context because
that's always correct in the specific error message.
Change-Id: I9aad8fcddf31ae53daa53cebd2c2001f08eabde0
Reviewed-on: https://go-review.googlesource.com/c/go/+/401316
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Before Go 1.18, an embedded type name in an interface could not be
parenthesized. With generalized embedding of types in interfaces,
where one might write ~(chan<- int) for clarity (making clear that
the ~ applies to the entire channel type), it also makes sense to
permit (chan<- int), or (int) for that matter.
Adjust the parser accordingly to match the spec.
(go/types already accepts the notation as specified by the spec.)
Fixes#52391.
Change-Id: Ifdd9a199c5ccc3473b2dac40dbca31d2df10d12b
Reviewed-on: https://go-review.googlesource.com/c/go/+/400797
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
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 <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
A run of lines that are indented with any number of spaces or tabs
format as a <pre> block. This commit fixes various doc comments
that format badly according to that (standard) rule.
For example, consider:
// - List item.
// Second line.
// - Another item.
Because the - lines are unindented, this is actually two paragraphs
separated by a one-line <pre> block. This CL rewrites it to:
// - List item.
// Second line.
// - Another item.
Today, that will format as a single <pre> block.
In a future release, we hope to format it as a bulleted list.
Various other minor fixes as well, all in preparation for reformatting.
For #51082.
Change-Id: I95cf06040d4186830e571cd50148be3bf8daf189
Reviewed-on: https://go-review.googlesource.com/c/go/+/384257
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
For syntax errors in various (syntactic) lists, instead of reporting
a set of "expected" tokens (which may be incomplete), provide context
and mention "possibly missing" tokens. The result is a friendlier and
more accurate error message.
Fixes#49205.
Change-Id: I38ae7bf62febfe790075e62deb33ec8c17d64476
Reviewed-on: https://go-review.googlesource.com/c/go/+/396914
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When parsing method declarations in an interface, the parser has
for historic reasons gracefully handled a list of method names with
a single (common) signature, and then reported an error. For example
interface {
m1, m2, m3 (x int)
}
This code originally came from the very first parser for Go which
initially permitted such declarations (or at least assumed that
people would write such declarations). Nobody is doing this at this
point, so there's no need for being extra careful here. Remove the
respective code and adjust the corresponding test.
Change-Id: If6f9b398bbc9e425dcd4328a80d8bf77c37fe8b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/396654
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Generics have landed; we cannot revert the syntax anymore. Remove
ability to choose between non-generic and generic code. Also remove
mode to enable method type parameters. Adjust code accordingly.
Also remove a couple of TODOs that are not relevant anymore.
Remove tests from types2 which were focussed on method type parameters,
make types2 and go/types tests match up where there was a difference in
this regard.
Change-Id: I989bdcb19eea7414214af739187fa013a044295d
Reviewed-on: https://go-review.googlesource.com/c/go/+/396634
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Move switch to enable method type parameters entirely
to the parser, by adding the mode AllowMethodTypeParams.
Ensure that the error messages are consistent.
Remove unnecessary code in the type checker.
Fixes#50317.
Change-Id: I4f3958722400bdb919efa4c494b85cf62f4002bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/376054
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The parser cannot distinguish a type parameter list of the form
[P *T ] or
[P (T)]
where T is not a type literal from an array length specification
P*T (product) or P(T) (constant-valued function call) and thus
interprets these forms as the start of array types.
This ambiguity must be resolved explicitly by placing *T inside
an interface, adding a trailing comma, or by leaving parentheses
away where possible.
This CL adjusts the parser such that these forms are
interpreted as (the beginning) of type parameter lists
if the token after P*T or P(T) is a comma, or if T is
a type literal.
This CL also adjusts the printer to print a comma if
necessary to avoid this ambiguity, and adds additional
printer tests.
Fixes#49482
Change-Id: I36328e2a7d9439c39ba0349837c445542549e84e
Reviewed-on: https://go-review.googlesource.com/c/go/+/370774
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This is a port of the idea used in CL 359134 from go/parser to syntax,
with adjustments due to the slightly different structure of the two
parsers, and some refactoring to simplify the logic.
Fixes#49175.
Change-Id: Ib4955bde708f2b08345f35523e6094c03ab3076c
Reviewed-on: https://go-review.googlesource.com/c/go/+/360135
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The respective issue has been accepted, so we can always
accept constraint literals with omitted interfaces.
For #48424.
Change-Id: Ia3d325401252a5a22d5ffa98d2ae6af73178dec0
Reviewed-on: https://go-review.googlesource.com/c/go/+/355709
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The type set notation has been accepted a while ago.
We're not going back to supporting the original
type list notation. Remove support for it in the
parser and type checker.
Change-Id: I860651f80b89fa43a3a5a2a02cf823ec0dae583c
Reviewed-on: https://go-review.googlesource.com/c/go/+/354131
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL permits an arbitrary type as well as the type sets ~T and A|B
in constraint position, without the need of a surrrounding interface.
For instance, the type parameter list
[P interface{ ~map[K]V }, K comparable, V interface{ ~string }]
may be written as
[P ~map[K]V, K comparable, V ~string]
The feature must be enabled explicitly with the AllowTypeSets mode
and is only available if AllowGenerics is set as well.
For #48424.
Change-Id: Ic70bb97a49ff75e67e040853eac10e6aed0fef1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/353133
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When parsing a type parameter declaration, parts of the code still
expected a ) as closing token. Use the correct follow token ) or ]
depending on parameter list kind.
Also, consistently use tokstring (not tok.String()) for user-facing
(error) messages.
Follow-up on comment in CL 348730.
For #43527.
Change-Id: Ib1d4feb526771a1668a54c3bb7a671f6c8a65940
Reviewed-on: https://go-review.googlesource.com/c/go/+/348742
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For #43527.
Change-Id: I8c706e68572286d5675383eb2dfd75b5618b646b
Reviewed-on: https://go-review.googlesource.com/c/go/+/348730
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Add (temporary) syntax.AllowTypeLists mode to control the
acceptance of type lists; the compiler doesn't set it,
but existing syntax and types2 tests do so that the code
remains exercised while it exists.
Adjust various tests to use the type set notation.
Change-Id: I798e607912552db6bfe38a7cd4324b74c6bf4d95
Reviewed-on: https://go-review.googlesource.com/c/go/+/347249
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Make sure the parser fills in names and types for type parameter
lists, even in the case of errors.
While at it, adjust some of the test functions to accept generic
code and report all syntax errors.
Added offending source as test for types2.
Fixes#47996.
Change-Id: I449bcf5e2cb80fa2a24cdd3945f484bfca218a06
Reviewed-on: https://go-review.googlesource.com/c/go/+/345476
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Change-Id: I8bca01b935301e7bd4efa55ed21921dbf31a75b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/344575
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
With types2, some syntax.PosBases need to be constructed from export
data, which must only contain "trimmed" filenames (i.e., that they've
already been made absolute and undergone -trimpath processing).
However, it's not safe to apply trimming to a filename multiple times,
and in general we can't distinguish trimmed from untrimmed filenames.
This CL resolves this by adding a PosBase.Trimmed boolean so we can
distinguish whether the associated filename has been trimmed yet. This
is a bit hacky, but is the least bad solution I've come up with so
far.
This unblocks enabling -G=3 by default.
Change-Id: I7383becfb704680a36f7603e3246af38b21f100b
Reviewed-on: https://go-review.googlesource.com/c/go/+/343731
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
For #47704.
Change-Id: I09e6f638df0cd456a20a3b68ab55c47bb5b1f555
Reviewed-on: https://go-review.googlesource.com/c/go/+/342370
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
End-users are not expected to deal with the details of panics,
so providing extra information such as an "internal error" prefix
is not helpful.
Matches the types2 changes made in https://golang.org/cl/339969 .
Change-Id: Icb34a9daab981a84f41f8ae7ae5dc1b85b2d2c81
Reviewed-on: https://go-review.googlesource.com/c/go/+/339904
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
