go/ast,go/parser: Decl field of type parameter identifier is nil for methods (but not for functions)

[aarzilli]

$ go version
go version devel go1.18-902dc38212 Tue Feb 1 16:52:46 2022 +0000 linux/amd64

See: https://gotipplay.golang.org/p/QhA7oB1-h54
For F, a generic funciton, the identifier T has a Decl field referring to the field in the type parameter list of F.
But for M, a method for a generic type, the identifier T` has a nil Decl field instead.

Is this intentional? Seems inconsistent.

cc @findleyr

[findleyr]

Thank you. No, this is not intentional. See also #45221, which may have missed methods.

Will try to fix for 1.18 (but not marking as a release blocker as we are trying to be very selective about release blockers at this point.

CC @griesemer

[gopherbot]

Change https://golang.org/cl/382247 mentions this issue: go/parser: resolve receiver type parameters

[findleyr]

I recalled incorrectly: as commented here we didn't resolve receiver type parameters because we weren't sure how to declare them: the docmentation for ast.Object.Decl does not (currently) allow for *ast.Ident's (the parameter expression) to be a declaration.

In general, syntactic object resolution is unreliable (it can be incorrect), slow, and of questionable value -- tools that need object resolution should probably use go/types. Also, if we make the API change to allow ast.Object.Decl to hold identifiers, we risk breaking working code.

@griesemer and I discussed this today and think we should consider this for 1.19, but probably shouldn't do anything for 1.18 at this point.

One thing that occurred to me, however, is that we could/should avoid incorrect object resolution involving type parameters. For example:

package p

type T struct{}
type P struct{}

func (T[P]) m(p P){}

In this example, because we don't declare the type parameter P, I think we'll resolve the struct type declaration for the P used in the signature of m. @griesemer what do you think about fixing this by declaring type parameters but not recording them when we resolve?

[griesemer]

@findleyr Fixing the incorrect resolution for 1.18 seems fine, if it is easy (which I think it might be). But if it's anything more than that, it's ok to defer at this point. We're veryclose to the release and object resolution is not a feature that we recommend using in the first place. We won't fix everything for 1.18 and this is certainly low priority.

[aarzilli]

syntactic object resolution is unreliable (it can be incorrect), slow, and of questionable value -- tools that need object resolution should probably use go/types.

object resolution is not a feature that we recommend using in the first place

Shouldn't this be documented somewhere? go/ast doesn't say anything about this and go/parser just documents the existence of SkipObjectResolution.

[findleyr]

Shouldn't this be documented somewhere? go/ast doesn't say anything about this and go/parser just documents the existence of SkipObjectResolution.

We should document this, however I think maybe we overstated a bit: I saw your CL and godoc is one place where syntactic object resolution makes sense and should generally work. I am not sure that it is 100% obvious that changing godoc to use go/types is a good change, as the performance implications are significant and imprecision is acceptable.

Unfortunately, at this point it is really too late to add a new Decl type to the documentation go/ast.Object, and this is possible to work-around (albeit awkwardly), so I will avoid the incorrect resolution in the associated CL, and move this to 1.19. We will address this in 1.19. Sorry.

[aarzilli]

We will address this in 1.19. Sorry.

No, I think it's a good decision.

[ianlancetaylor]

@griesemer @findleyr This is the 1.19 milestone. Move to 1.20? To Backlog? Thanks.

[findleyr]

Let's move to 1.20; we may or not do this depending on the outcome of #52463

[griesemer]

@findleyr What's the status of this issue? Given that object resolution is now deprecated, is there anything we should be doing here? Should this move to 1.23?