-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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: inner CompositeLit T{{x}} has no type #69092
Comments
Change https://go.dev/cl/616616 mentions this issue: |
@adonovan FWIW, the above CL addresses this particular issue. Note though that while in More generally, it may be very difficult to impossible to provide even invalid types for expressions that cannot be properly type checked by the type checker. It seems that this may be better handled on the tools side, because the work only needs to be done if one expects to deal with incorrect programs in the first place. |
Change https://go.dev/cl/617475 mentions this issue: |
The fix for golang/go#69092 produces an extra error message in Go 1.24. Ignore it. Updates golang/go#68918. Updates golang/go#69092. Change-Id: I41ecff6fe916a04ed943e29ad10184d340ef84d5 Reviewed-on: https://go-review.googlesource.com/c/tools/+/617475 Reviewed-by: Alan Donovan <adonovan@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
I was going to disagree, as I had believed that it was (modulo bugs) an invariant that every Expr had a type, but I just audited x/tools and found that nearly 100% of places that look at Info.Types handle a missing entry, or are dominated by a check that type-checking was error-free. This is too high to be a coincidence. Furthermore, I notice in the types playground that it is easy to make an ill-formed expression that has no type. So, I think we have generally been conservative in our tools, and that I made a mistake in filing this issue. The "workaround" in gopls was in fact just the correct defensive code. Sorry for taking up your time. I do think it would be valuable to record the non-invariant at Info.Types. |
Huh, we already do: type Info struct {
// Types maps expressions to their types, and for constant
// expressions, also their values. Invalid expressions are
// omitted. [...]
Types map[ast.Expr]TypeAndValue How embarrassing. |
Change https://go.dev/cl/617416 mentions this issue: |
When the type checker encounters an ill-typed composite literal, it does not descend into any inner composite literals (because it has no type to propagate downwards) so they have no recorded type.
Minimal repro in the types playground:
var _ = T{{x}}
. Observe that the outer has type Invalid, the inner no type at all.This is the root cause of #68918.
The text was updated successfully, but these errors were encountered: