aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/syntax/parser.go
AgeCommit message (Collapse)Author
2025-02-03go/parser, go/types, syntax, types2: report invalid uses of ... by parsersRobert Griesemer
Check correct use of ...'s in parameter lists in parsers. This allows the type checkers to assume correct ASTs with respect to ... use. Adjust some error messages: if a ... is used in a result parameter list, the error is now more accurate. Eliminate a now unused error code. Change-Id: I66058e114e84805e24c59e570604b607ef5ff1fe Reviewed-on: https://go-review.googlesource.com/c/go/+/631135 Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Bypass: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com>
2024-11-14cmd/compile: better error message when offending/missing token is a keywordRobert Griesemer
Prefix keywords (type, default, case, etc.) with "keyword" in error messages to make them less ambiguous. Fixes #68589. Change-Id: I1eb92d1382f621b934167b3a4c335045da26be9f Reviewed-on: https://go-review.googlesource.com/c/go/+/623819 Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Tim King <taking@google.com>
2024-09-30go/parser, syntax: better error message for parameter missing typeRobert Griesemer
Fixes #69506. Change-Id: I18215e11f214b12d5f65be1d1740181e427f8817 Reviewed-on: https://go-review.googlesource.com/c/go/+/617015 Reviewed-by: Alan Donovan <adonovan@google.com> Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-09-05cmd/compile/internal/syntax: handle parentheses around constraints consistentlyRobert Griesemer
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>
2024-07-30go/types: record pointer and parentheses in receiver expressionsRobert Griesemer
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>
2024-05-30cmd/compile: remove quoting in favor of clearer prose in error messagesRobert Griesemer
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>
2024-02-27cmd/compile: use quotes to wrap user-supplied tokenZxilly
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>
2023-11-02go/parser: better error messages for incorrect type parameter listRobert Griesemer
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>
2023-11-01cmd/compile/internal/syntax: better error messages for incorrect type ↵Robert Griesemer
parameter list 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>
2023-11-01cmd/compile/internal/syntax: fix/update various commentsRobert Griesemer
Change-Id: I30b448c8fcdbad94afcd7ff0dfc5cfebb485bdd7 Reviewed-on: https://go-review.googlesource.com/c/go/+/538855 Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
2023-10-31cmd/compile/internal/syntax: set up dummy name and type if func name is missingRobert Griesemer
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>
2023-08-24cmd/compile/internal/syntax: use strings.LastIndexByte in trailingDigitsTobias Klauser
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>
2023-08-24cmd/compile/internal/syntax: add Unparen and UnpackListExpr helpersMatthew Dempsky
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>
2023-06-06cmd/compile/internal/syntax: better error message when using = instead of ==Robert Griesemer
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>
2023-04-13go/parser: report //go:build-derived Go version in ast.File.GoVersionRuss Cox
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>
2022-12-03all: fix some comments for methodcui fliter
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>
2022-10-05cmd/compile/internal/syntax: better error message for erroneous method ↵Robert Griesemer
declaration 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>
2022-09-22cmd/compile/internal/syntax: remove TypeList syntax in commentKevin Chen
Change-Id: Ic4df6a8e198b069a9f3a28710fa40f29bd658b06 GitHub-Last-Rev: 51040eb5e53f4cf0238cb0b7876d1ee612a924ef GitHub-Pull-Request: golang/go#55345 Reviewed-on: https://go-review.googlesource.com/c/go/+/432795 Run-TryBot: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2022-09-02cmd/compile/internal/syntax: more strict parsing of type instancesRobert Griesemer
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>
2022-09-02cmd/compile/internal/syntax: more tolerant parsing of import declarationsRobert Griesemer
Change-Id: I114548640d51bf69833259578609901fa1602510 Reviewed-on: https://go-review.googlesource.com/c/go/+/427156 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Robert Griesemer <gri@google.com>
2022-09-01go/parser: leave checking of LHS in short var decls to type checkerRobert Griesemer
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>
2022-09-01cmd/compile: avoid "not used" errors due to bad go/defer statementsRobert Griesemer
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>
2022-09-01go/parser: adjustments to error messagesRobert Griesemer
- 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>
2022-09-01cmd/compile/internal/syntax: use BadExpr instead of fake CallExpr in bad ↵Robert Griesemer
go/defer 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>
2022-08-18cmd/compile/internal/syntax: handle missing index like in go/parserRobert Griesemer
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>
2022-05-04cmd/compile/internal/syntax: minor cleanups in extractNameRobert Griesemer
Backport the recommended changes suggested in CL 403937. Change-Id: I3ac29c90977e33899881838825da033627344ed2 Reviewed-on: https://go-review.googlesource.com/c/go/+/403853 Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@google.com>
2022-05-03cmd/compile/internal/syntax: accept all valid type parameter listsRobert Griesemer
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>
2022-04-26cmd/compile/internal/syntax: parser to accept ~x as unary expressionRobert Griesemer
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>
2022-04-20cmd/compile/internal/syntax: correct an error stringRobert Griesemer
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>
2022-04-19cmd/compile/internal/types2: permit parentheses around types in interfacesRobert Griesemer
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>
2022-04-01all: remove trailing blank doc comment linesRuss Cox
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>
2022-04-01all: fix various doc comment formatting nitsRuss Cox
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>
2022-03-31cmd/compile/internal/syntax: better errors for syntax errors in listsRobert Griesemer
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>
2022-03-30cmd/compile/internal/syntax: remove code dealing with multiple method namesRobert Griesemer
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>
2022-03-30cmd/compile/internal/syntax: remove generic-specific parse modesRobert Griesemer
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>
2022-01-06cmd/compile: report type parameter error for methods only onceRobert Griesemer
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>
2021-12-17cmd/compile/internal/syntax: fix parsing of type parameter listsRobert Griesemer
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>
2021-11-04cmd/compile/internal/syntax: better error message when type parameters are ↵Robert Griesemer
not permitted Fixes #48382. Change-Id: I215896a4429839c41c9136b6922b1b748ed47734 Reviewed-on: https://go-review.googlesource.com/c/go/+/361259 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2021-10-31cmd/compile/internal/syntax: fix parsing of array or slice constraint typesRobert Griesemer
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>
2021-10-27cmd/compile/internal/syntax: fix constraint literal parsing for generic ↵Robert Griesemer
functions Fixes #49174. Change-Id: I943c370f7abd5f50a541e682f130b3526c3b5bdb Reviewed-on: https://go-review.googlesource.com/c/go/+/359014 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2021-10-14cmd/compile/internal/syntax: remove AllowTypeSets modeRobert Griesemer
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>
2021-10-06cmd/compile/internal/syntax, types2: remove ability to handle type listsRobert Griesemer
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>
2021-10-01cmd/compile/internal/syntax: allow eliding interface in constraint literalsRobert Griesemer
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>
2021-09-10cmd/compile/internal/syntax: correct follow token for type parameter listsRobert Griesemer
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>
2021-09-09cmd/compile/internal/syntax: better error message for missing type constraintRobert Griesemer
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>
2021-09-02cmd/compile: disable type list syntax for the compilerRobert Griesemer
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>
2021-08-27cmd/compile/internal/syntax: make valid type parameter list in presence of ↵Robert Griesemer
errors 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>
2021-08-25cmd/compile/internal/syntax: fix position of type parameter fieldRobert Griesemer
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>
2021-08-20cmd/compile/internal/syntax: add PosBase.TrimmedMatthew Dempsky
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>
2021-08-15cmd/compile/internal/types2: better error message for index syntax error ↵Robert Griesemer
(follow-up) 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>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 12:05:25 +0000