Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

go/types, types2: consider interpreting type X [P]T as generic type with missing constraint if P is not declared #56064

Closed
griesemer opened this issue Oct 5, 2022 · 6 comments
Assignees
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@griesemer
Copy link
Contributor

See #55961 for back story.

@griesemer griesemer added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 5, 2022
@griesemer griesemer added this to the Backlog milestone Oct 5, 2022
@griesemer griesemer self-assigned this Oct 5, 2022
@griesemer
Copy link
Contributor Author

The argument is that it is more likely that

type X[P] <some type literal>

where P is not defined, is a generic type declaration with missing constraint (e.g., any) rather than an array type declaration with missing array length P.

@griesemer
Copy link
Contributor Author

cc: @mdempsky @findleyr for feedback.

@mdempsky
Copy link
Member

mdempsky commented Oct 6, 2022

This sounds reasonable to me.

One concern is how to handle follow-on errors. E.g., I think ideally go/types would only report "P is undeclared" for the package below, though even today it also reports "cannot index a (variable of type X)". So it seems okay if we instead report a spurious "cannot use X without instantiation" error.

package p

type X [P]int

var a X
var b int = a[0]

@gopherbot
Copy link

Change https://go.dev/cl/439476 mentions this issue: go/types, types2: better error for generic type decl. with missing constraint

@gopherbot
Copy link

Change https://go.dev/cl/439559 mentions this issue: go/types, types2: better error for generic type decl. with missing constraint

@griesemer
Copy link
Contributor Author

Per discussion on the CL, while it's not hard to interpret an array declaration with an undefined length identifier as a generic type declaration with a missing type constraint, the re-interpretation leads to incorrect population of the various type-checker maps used by tools. Instead, opt for a better error message about the invalid array length.

gopherbot pushed a commit that referenced this issue Oct 10, 2022
…nstraint

If a generic type declaration is missing a constraint, syntactically
it is an array type declaration with an undefined array length.
Mention the possibility of a missing constraint in the error message
for the undefined array length.

For #56064.
For #55961.
For #51145.

Change-Id: Ic161aeda9ea44faa8aa3bf3e9d62b3b13a95d4c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/439559
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
romaindoumenc pushed a commit to TroutSoftware/go that referenced this issue Nov 3, 2022
…nstraint

If a generic type declaration is missing a constraint, syntactically
it is an array type declaration with an undefined array length.
Mention the possibility of a missing constraint in the error message
for the undefined array length.

For golang#56064.
For golang#55961.
For golang#51145.

Change-Id: Ic161aeda9ea44faa8aa3bf3e9d62b3b13a95d4c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/439559
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
@golang golang locked and limited conversation to collaborators Oct 6, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

3 participants