summaryrefslogtreecommitdiff
path: root/src/cmd/compile/internal/syntax/parser.go
Commit message (Collapse)AuthorAgeFilesLines
* cmd/compile/internal/syntax: minor cleanups in extractNameRobert Griesemer2022-05-041-3/+3
| | | | | | | | | | | 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>
* cmd/compile/internal/syntax: accept all valid type parameter listsRobert Griesemer2022-05-031-51/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: parser to accept ~x as unary expressionRobert Griesemer2022-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: correct an error stringRobert Griesemer2022-04-201-1/+1
| | | | | | | | | | | | | 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>
* cmd/compile/internal/types2: permit parentheses around types in interfacesRobert Griesemer2022-04-191-37/+7
| | | | | | | | | | | | | | | | | | | | 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>
* all: remove trailing blank doc comment linesRuss Cox2022-04-011-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* all: fix various doc comment formatting nitsRuss Cox2022-04-011-24/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: better errors for syntax errors in listsRobert Griesemer2022-03-311-8/+8
| | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: remove code dealing with multiple method namesRobert Griesemer2022-03-301-14/+0
| | | | | | | | | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: remove generic-specific parse modesRobert Griesemer2022-03-301-124/+85
| | | | | | | | | | | | | | | | | 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>
* cmd/compile: report type parameter error for methods only onceRobert Griesemer2022-01-061-3/+9
| | | | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: fix parsing of type parameter listsRobert Griesemer2021-12-171-33/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: better error message when type parameters are ↵Robert Griesemer2021-11-041-17/+28
| | | | | | | | | | | 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>
* cmd/compile/internal/syntax: fix parsing of array or slice constraint typesRobert Griesemer2021-10-311-33/+49
| | | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: fix constraint literal parsing for generic ↵Robert Griesemer2021-10-271-1/+13
| | | | | | | | | | | 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>
* cmd/compile/internal/syntax: remove AllowTypeSets modeRobert Griesemer2021-10-141-1/+1
| | | | | | | | | | | | 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>
* cmd/compile/internal/syntax, types2: remove ability to handle type listsRobert Griesemer2021-10-061-31/+2
| | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: allow eliding interface in constraint literalsRobert Griesemer2021-10-011-17/+51
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: correct follow token for type parameter listsRobert Griesemer2021-09-101-6/+8
| | | | | | | | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: better error message for missing type constraintRobert Griesemer2021-09-091-6/+16
| | | | | | | | | | | 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>
* cmd/compile: disable type list syntax for the compilerRobert Griesemer2021-09-021-3/+8
| | | | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: make valid type parameter list in presence of ↵Robert Griesemer2021-08-271-4/+1
| | | | | | | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: fix position of type parameter fieldRobert Griesemer2021-08-251-1/+5
| | | | | | | | | 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>
* cmd/compile/internal/syntax: add PosBase.TrimmedMatthew Dempsky2021-08-201-1/+3
| | | | | | | | | | | | | | | | | | | | | | | 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>
* cmd/compile/internal/types2: better error message for index syntax error ↵Robert Griesemer2021-08-151-3/+8
| | | | | | | | | | | | | (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>
* cmd/compile/internal/syntax: better error message for index syntax errorRobert Griesemer2021-08-151-1/+5
| | | | | | | | | | | 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>
* [dev.typeparams] cmd/compile/internal/syntax: cleanup panic callsRobert Griesemer2021-08-061-1/+1
| | | | | | | | | | | | | | 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>
* [dev.typeparams] cmd/compile/internal/syntax: not all index expressions can ↵Robert Griesemer2021-06-051-1/+16
| | | | | | | | | | | | | | | | | | 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>
* [dev.typeparams] cmd/compile/internal/syntax: accept embedded type literalsRobert Griesemer2021-05-191-0/+12
| | | | | | | | | | | | | 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>
* cmd/compile/internal/types2: catch unexpected expression listsRobert Griesemer2021-04-281-7/+6
| | | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: fix error message for ... without typeRobert Griesemer2021-04-151-1/+1
| | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: accept "~" and "|" interface elementsRobert Griesemer2021-04-101-14/+78
| | | | | | | | | | | | | | 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>
* [dev.typeparams] cmd/compile: use nil instead of syntax.ImplicitOneRobert Griesemer2021-01-211-5/+1
| | | | | | | | | | | | | | | 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>
* [dev.typeparams] cmd/compile/internal/syntax: type parameters must always be ↵Robert Griesemer2020-12-161-10/+24
| | | | | | | | | | | | | | 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>
* [dev.typeparams] cmd/compile/internal/types2: don't crash if import path is ↵Robert Griesemer2020-12-151-11/+11
| | | | | | | | | | | | | | | | | | | | | | 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>
* [dev.typeparams] cmd/compile/internal/syntax: export NewName and use itRobert Griesemer2020-12-141-17/+6
| | | | | | | | | | | | | | | | | 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>
* [dev.typeparams] cmd/compile/internal/syntax: always use IndexExpr node for ↵Robert Griesemer2020-10-141-83/+133
| | | | | | | | | | | | | | | | | | | 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>
* [dev.typeparams] cmd/compile/internal/syntax: implement parsing of type ↵Robert Griesemer2020-10-131-202/+441
| | | | | | | | | | | | | | | | | 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>
* [dev.typeparams] cmd/compile/internal/syntax: prepare syntax nodes for type ↵Robert Griesemer2020-10-131-1/+1
| | | | | | | | | | | | | | 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>
* cmd/compile/internal/syntax: provide BadExpr where needed, call correct ↵Robert Griesemer2020-10-121-1/+9
| | | | | | | | | | | | | | | | | | | | | 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>
* cmd/compile: detect and diagnose invalid //go: directive placementRuss Cox2020-04-211-18/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Thie CL changes cmd/compile/internal/syntax to give the gc half of the compiler more control over pragma handling, so that it can prepare better errors, diagnose misuse, and so on. Before, the API between the two was hard-coded as a uint16. Now it is an interface{}. This should set us up better for future directives. In addition to the split, this CL emits a "misplaced compiler directive" error for any directive that is in a place where it has no effect. I've certainly been confused in the past by adding comments that were doing nothing and not realizing it. This should help avoid that kind of confusion. The rule, now applied consistently, is that a //go: directive must appear on a line by itself immediately before the declaration specifier it means to apply to. See cmd/compile/doc.go for precise text and test/directive.go for examples. This may cause some code to stop compiling, but that code was broken. For example, this code formerly applied the //go:noinline to f (not c) but now will fail to compile: //go:noinline const c = 1 func f() {} Change-Id: Ieba9b8d90a27cfab25de79d2790a895cefe5296f Reviewed-on: https://go-review.googlesource.com/c/go/+/228578 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
* cmd/compile/internal/syntax: faster and simpler source readerRobert Griesemer2020-03-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is one of several changes that were part of a larger rewrite which I made in early 2019 after switching to the new number literal syntax implementation. The purpose of the rewrite was to simplify reading of source code (Unicode character by character) and speed up the scanner but was never submitted for review due to other priorities. Part 3 of 3: This change contains a complete rewrite of source.go, the file that implements reading individual Unicode characters from the source. The new implementation is easier to use and has simpler literal buffer management, resulting in faster scanner and thus parser performance. Thew new source.go (internal) API is centered around nextch() which advances the scanner by one character. The scanner has been adjusted around nextch() and now consistently does one character look-ahead (there's no need for complicated ungetr-ing anymore). Only in one case backtrack is needed (when finding '..' rather than '...') and that case is now more cleanly solved with the new reset() function. Measuring line/s parsing peformance by running go test -run StdLib -fast -skip "syntax/(scanner|source)\.go" (best of 5 runs on "quiet" MacBook Pro, 3.3GHz Dual-Core i7, 16GB RAM, OS X 10.15.3) before and after shows consistently 3-5% improvement of line parsing speed: old: parsed 1788155 lines (3969 files) in 1.255520307s (1424234 lines/s) new: parsed 1788155 lines (3969 files) in 1.213197037s (1473919 lines/s) (scanner.go and parser.go are skipped because this CL changed those files.) Change-Id: Ida947f4b538d42eb2d2349062c69edb6c9e5ca66 Reviewed-on: https://go-review.googlesource.com/c/go/+/221603 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* cmd/compile/internal/syntax: better error when an assignment is used in ↵Robert Griesemer2020-02-211-3/+8
| | | | | | | | | | | | | | | | | value context The error message is now positioned at the statement position (which is an identifing token, such as the '=' for assignments); and in case of assignments it emphasizes the assignment by putting the Lhs and Rhs in parentheses. Finally, the wording is changed from "use of * as value" to the stronger "cannot use * as value" (for which there is precedent elsewhere in the parser). Fixes #36858. Change-Id: Ic3f101bba50f58e3a1d9b29645066634631f2d61 Reviewed-on: https://go-review.googlesource.com/c/go/+/218337 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* cmd/compile/internal/syntax: add BasicLit.Bad field for lexical errorsRobert Griesemer2019-08-291-7/+8
| | | | | | | | | | | | | | | | | | The new (internal) field scanner.bad indicates whether a syntax error occurred while scanning a literal; the corresponding scanner.lit string may be syntactically incorrect in that case. Store the value of scanner.bad together with the scanner.lit in BasicLit. Clean up error handling so that all syntactic errors use one of the scanner's error reporting methods which also set scanner.bad. Make use of the new field in a few places where we used to track a prior error separately. Preliminary step towards fixing #32133 in a comprehensive manner. Change-Id: I4d79ad6e3b50632dd5fb3fc32ca3df0598ee77b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/192278 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* cmd/compile/internal/syntax: better error recovery after missing expressionRobert Griesemer2019-08-271-1/+4
| | | | | | | | | | | | Don't skip closing parentheses of any kind after a missing expression. They are likely part of the lexical construct enclosing the expression. Fixes #33386. Change-Id: Ic0abc2037ec339a345ec357ccc724b7ad2a64c00 Reviewed-on: https://go-review.googlesource.com/c/go/+/188502 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* cmd/compile: better recovery after := (rather than =) in declarationsRobert Griesemer2019-04-031-4/+18
| | | | | | | | | | | | | Before this fix, a mistaken := in a (const/type/var) declaration ended that declaration with an error from which the parser didn't recover well. This low-cost change will provide a better error message and lets the parser recover perfectly. Fixes #31092. Change-Id: Ic4f94dc5e29dd00b7ef6d53a80dded638e3cea80 Reviewed-on: https://go-review.googlesource.com/c/go/+/169958 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* cmd/compile/internal/syntax: better error message for incorrect if/switch headerRobert Griesemer2018-04-031-1/+2
| | | | | | | | | Fixes #23664. Change-Id: Ic0637e9f896b2fc6502dfbab2d1c4de3c62c0bd2 Reviewed-on: https://go-review.googlesource.com/104616 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Robert Griesemer <gri@golang.org>
* cmd/compile: better handling of incorrect type switchesRobert Griesemer2018-04-031-44/+29
| | | | | | | | | | | | | | | | | | | Don't report errors if we don't have a correct type switch guard; instead ignore it and leave it to the type-checker to report the error. This leads to better error messages concentrating on the type switch guard rather than errors around (confusing) syntactic details. Also clean up some code setting up AssertExpr (they never have a nil Type field) and remove some incorrect TODOs. Fixes #24470. Change-Id: I69512f36e0417e3b5ea9c8856768e04b19d654a8 Reviewed-on: https://go-review.googlesource.com/103615 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* cmd/compile, cmd/compile/internal/syntax: print relative column infoRobert Griesemer2018-02-281-12/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change enables printing of relative column information if a prior line directive specified a valid column. If there was no line directive, or the line directive didn't specify a column (or the -C flag is specified), no column information is shown in file positions. Implementation: Column values (and line values, for that matter) that are zero are interpreted as "unknown". A line directive that doesn't specify a column records that as a zero column in the respective PosBase data structure. When computing relative columns, a relative value is zero of the base's column value is zero. When formatting a position, a zero column value is not printed. To make this work without special cases, the PosBase for a file is given a concrete (non-0:0) position 1:1 with the PosBase's line and column also being 1:1. In other words, at the position 1:1 of a file, it's relative positions are starting with 1:1 as one would expect. In the package syntax, this requires self-recursive PosBases for file bases, matching what cmd/internal/src.PosBase was already doing. In src.PosBase, file and inlining bases also need to be based at 1:1 to indicate "known" positions. This change completes the cmd/compiler part of the issue below. Fixes #22662. Change-Id: I6c3d2dee26709581fba0d0261b1d12e93f1cba1a Reviewed-on: https://go-review.googlesource.com/97375 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* cmd/compile/internal/syntax: implement //line :line:col handlingRobert Griesemer2018-02-261-3/+10
| | | | | | | | | | | | | | | For line directives which have a line and a column number, an omitted filename means that the filename has not changed (per the issue below). For line directives w/o a column number, an omitted filename means the empty filename (to preserve the existing behavior). For #22662. Change-Id: I32cd9037550485da5445a34bb104706eccce1df1 Reviewed-on: https://go-review.googlesource.com/96476 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
View Lorry Controller Status