For yet more context and an example:

func f() { print("there") }
func foo() {
  f := func() { print("here") }
  go f()
}

The question I am having trouble answering is what are the guarantees on the *ast.Ident.Obj field for the "f" in go f() given by the "go/ast" package.

Ident.Obj may be nil if the referenced declaration is in another file. It also may be incorrect, as in

var f int
var _ = M{f: "foo"}

(the parser doesn't know whether the use of 'f' is as a struct field or map key).

We could try to document the exact rules, but in general there are problems with syntactic object resolution, and it is better to use go/types wherever possible. Would that be possible in the CL in question?

See also #45104. While working on that refactoring, I discovered a couple other edge cases where Ident.Obj was wrong or missing when it shouldn't have been, and prior to that change there was very little test coverage. I actually hesitate to commit to strict semantics, because I don't think we want to encourage reliance on Ident.Obj.

We could try to document the exact rules,

I don't think we need something exact. Just enough to know what ast.Ident.Obj == nil implies (or if it is just "optional"). If the answer is package scope, the original CL was already correct. If the answer is really complicated then various cmd/vet checkers should probably steer clear anyways.

it is better to use go/types wherever possible. Would that be possible in the CL in question?

I think so. What we ultimately needed that context is the ast for the function body. We can sanity check that the function decl found using the ast.Scope has the same Pos as the types.Info.Use (and is not token.NoPos) for the *ast.Ident we are checking.

Change https://golang.org/cl/347089 mentions this issue: go/analysis/passes/testinggoroutine: fix panic in goStmtFun

The question I am having trouble answering is what are the guarantees on the *ast.Ident.Obj field for the "f" in go f() given by the "go/ast" package.

I believe this is guaranteed to resolve to the f in the same scope. I think in case of the same file, we are guaranteed to have a non-nil Ident.Obj, if Ident.Obj is nil, then the referenced declaration is in another file.

We could try to document the exact rules, but in general there are problems with syntactic object resolution, and it is better to use go/types wherever possible. Would that be possible in the CL in question?

We need the function declaration AST only, that's why I can't use go/types :(

I think we just need to document that Ident.Obj is nil in case the referenced declaration is in another file of the same package, otherwise, an error was already raised.

Change https://golang.org/cl/347530 mentions this issue: go/ast: clarify when Ident.Obj is nil

Left a comment on your CL; we can say something about what it means for Ident.Obj to be nil, but we should be careful to be accurate.

Yes, you should be able to rely on identifiers being resolved to declarations within the function scope.

Re-opening as we're discussing the documentation (on the CL above), and it still needs some improvement.

Change https://golang.org/cl/347592 mentions this issue: Revert "go/ast: clarify when Ident.Obj is nil"

See also #52463

Change https://go.dev/cl/504915 mentions this issue: go/ast: deprecate Object

@adonovan, hi!

Question about

go/ast: deprecate Object

How to receive AST declaration from types.Object (like old ast.Object.Decl field)?

How to receive AST declaration from types.Object (like old ast.Object.Decl field)?

The Defs field of types.Info gives you the Ident of the declaration. If you want the declaration itself (e.g. FuncDecl, VarDecl), then you need to "walk up" the tree, but since it doesn't have parent pointers you actually need to walk down the tree looking for the declaration enclosing the identifier.

If you're know you're looking for a package-level declaration (e.g. a global var, or a named function), you can iterate over File.Decls. Or you can use astutil.PathEnclosingInterval to find all enclosing nodes. (Internally, it walks down the tree.)

It's more work, there's no denying it.

P.S. I've long been meaning to add a faster version of PathEnclosingInterval that isn't as clever about whitespace and internal tokens (see the comments on that function to know what I'm talking about) as most callers don't need it, and it makes it slower.

If you want the declaration itself (e.g. FuncDecl, VarDecl), then you need to "walk up" the tree, but since it doesn't have parent pointers

The nilness was documented by https://golang.org/cl/347592. The deprecation documentation in https://go.dev/cl/504915 included the advice to use go/types. Marking as complete.