aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/syntax/parser.go
AgeCommit message (Collapse)Author
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>
2021-08-15cmd/compile/internal/syntax: better error message for index syntax errorRobert Griesemer
Fixes #47704. Change-Id: I1de9fd00baaa4b534c23f011ade54120f5153a9d Reviewed-on: https://go-review.googlesource.com/c/go/+/342369 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-06[dev.typeparams] cmd/compile/internal/syntax: cleanup panic callsRobert Griesemer
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>
2021-06-05[dev.typeparams] cmd/compile/internal/syntax: not all index expressions can ↵Robert Griesemer
be instantiated types An index expression followed by an opening "{" may indicate a composite literal but only if the index expression can be a type. Exclude cases where the index expression cannot be a type (e.g. s[0], a[i+j], etc.). This leads to a better error message in code that is erroneous. Fixes #46558. Change-Id: Ida9291ca30683c211812dfb95abe4969f44c474f Reviewed-on: https://go-review.googlesource.com/c/go/+/325009 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2021-05-19[dev.typeparams] cmd/compile/internal/syntax: accept embedded type literalsRobert Griesemer
The parser accepted embedded elements but the first term of an element had to be a ~-term or a type name. This CL fixes that. Change-Id: I013b6cdc5963fb228867ca6597f9139db2be7ec5 Reviewed-on: https://go-review.googlesource.com/c/go/+/321109 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-04-28cmd/compile/internal/types2: catch unexpected expression listsRobert Griesemer
This is a modified port of the https://golang.org/cl/313909 change for go/types. - add catch-all cases for unexpected expression lists - add Checker.singleIndex function to check single indices - better syntax error handling in parser for invalid type instantiations that are missing a type argument Change-Id: I6f0f396d637ad66b79f803d886fdc20ee55a98b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/314409 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2021-04-15cmd/compile/internal/syntax: fix error message for ... without typeRobert Griesemer
Only complain about missing type; leave it to type-checking to decide whether "..." is permitted in the first place. Fixes #43674. Change-Id: Icbc8f084e364fe3ac16076406a134354219c08d0 Reviewed-on: https://go-review.googlesource.com/c/go/+/310209 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-04-10cmd/compile/internal/syntax: accept "~" and "|" interface elementsRobert Griesemer
Type lists continue to be accepted as before. While at it, print missing filenames in error tests (which uses an ad-hoc position representation). Change-Id: I933b3acbc9cf1985ad8f70f6b206e3a1dbd64d1e Reviewed-on: https://go-review.googlesource.com/c/go/+/307371 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-01-21[dev.typeparams] cmd/compile: use nil instead of syntax.ImplicitOneRobert Griesemer
Represent x++/-- as x +=/-= with the RHS of the assignment being nil rather than syntax.ImplicitOne. Dependent code already had to check for syntax.ImplicitOne, but then shared some existing code for regular assignment operations. Now always handle this case fully explicit, which simplifies the code. Change-Id: I28c7918153c27cbbf97b041d0c85ff027c58687c Reviewed-on: https://go-review.googlesource.com/c/go/+/285172 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2020-12-16[dev.typeparams] cmd/compile/internal/syntax: type parameters must always be ↵Robert Griesemer
named Report an error otherwise. Change-Id: Ia76ea03a3f26b13dd9bca49f7bd42101d1ff1f9e Reviewed-on: https://go-review.googlesource.com/c/go/+/278475 Trust: Robert Griesemer <gri@golang.org> Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2020-12-15[dev.typeparams] cmd/compile/internal/types2: don't crash if import path is ↵Robert Griesemer
missing In package syntax: - fix parser appendGroup to not add nil entries - non-string paths are syntax errors per the spec; report in parser - document ImportDecl.Path invariants In package types2: - guard against absent paths In package gc: - guard against absent paths Fixes #43190. Change-Id: Ic6a06f6a96b7f519feaa1ceaf4376fc5ab0f0129 Reviewed-on: https://go-review.googlesource.com/c/go/+/278114 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
2020-12-14[dev.typeparams] cmd/compile/internal/syntax: export NewName and use itRobert Griesemer
Most syntax.Nodes are allocated in one place and there didn't seem a need to provide factory methods - so as a matter of API design, all nodes are "naked", without any constructors. However, Name nodes are frequently used/replaced and also are created as helper nodes in clients (types2). Make an exception and export NewName. Change-Id: I4b5c499d65bba74592dea68b0936c118b3edaca7 Reviewed-on: https://go-review.googlesource.com/c/go/+/277572 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>
2020-10-14[dev.typeparams] cmd/compile/internal/syntax: always use IndexExpr node for ↵Robert Griesemer
type instantiation Per @mdempsky's suggestion: Instead of representing a type instantiation T[P] by an IndexExpr node, and a type instantiation with multiple type arguments T[P1, P2] by a CallExpr node with special Brackets flag, always use an IndexExpr. Use a ListExpr as index in the (less common) case of multiple type arguments. This removes the need for the CallExpr.Brackets field and cleans up the parser code around type instantiations. Backport of syntax package changes from https://golang.org/cl/262020. Change-Id: I32e8bc4eafac5b3ef2e7eb40fa8c790a5a905b69 Reviewed-on: https://go-review.googlesource.com/c/go/+/262137 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2020-10-13[dev.typeparams] cmd/compile/internal/syntax: implement parsing of type ↵Robert Griesemer
parameters Port from dev.go2go prototype branch. The compiler doesn't yet set the syntax.AllowGenerics mode, so parsing of generic code remains disabled. Known issue: The doc strings documenting the specific syntax accepted by parser methods are not all up-to-date. Change-Id: I13d134289fd9330fd0ed7f97c997cca6f23466fd Reviewed-on: https://go-review.googlesource.com/c/go/+/261658 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>
2020-10-13[dev.typeparams] cmd/compile/internal/syntax: prepare syntax nodes for type ↵Robert Griesemer
parameters - add TParamList fields to TypeDecl, FuncDecl - also: change File.Lines to File.EOF so we have the actual file end position Change-Id: Ia345f888080a884f7ac5cefd8bff3d80e4a59cdc Reviewed-on: https://go-review.googlesource.com/c/go/+/261657 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>
2020-10-12cmd/compile/internal/syntax: provide BadExpr where needed, call correct ↵Robert Griesemer
error handler - For "if" statements without a condition, provide a BadExpr rather than nil (clients expect IfStmt.Cond != nil since the parser is taking care of reporting a missing condition). - For 3-index slice expressions, also provide BadExpr where an index is required but missing. - Declare a parser-local error method to hide the embedded error method so we don't use it by mistake. Accidentally found while adjusting prototype parser to work for generics. Change-Id: Iacc211cc60869be05efe9ae630d65dff1dac00a0 Reviewed-on: https://go-review.googlesource.com/c/go/+/261218 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 20:58:51 +0000