I think the gogrep entry is a bit confusing :) The link doesn't point to a Go analysis tool, and the linked issue is about support for modules. Also, note that the actual repo has been archived, so I think we can just omit it entirely, unless there's a healthy fork somewhere.

For gofumpt, I think it already supports type parameters (https://github.com/mvdan/gofumpt/blob/ba9bdf90c2757f830763edbfb9ab401a50012fa8/testdata/scripts/typeparams.txt), so we can probably mark it as done unless there's a specific bug or missing feature you can point me to.

I think the gogrep entry is a bit confusing :)

Whoops! I started with the list from #24661, and missed that link. I removed the gogrep item, and marked gofumpt as done. Thanks!

In terms of the other tools, you already mentioend #50447, and I think #48525 also deserves a mention as a blocker. Some static analysis tools, like unparam or staticcheck, depend on SSA.

Hi @findleyr One thing that might be helpful is a pointer to a body of generic Go code to test against?

For example, I've pitched in a bit on dvyukov/go-fuzz, and I've confirmed that a hello world generic target seems to work, but I suspect more complicated examples might have problems. A while ago, I pulled together a small set of generics examples, but probably not representative enough, and it might be helpful to have a pointer here to a good set of examples.

Also, in case you haven't already seen this, there is a list of ~80 utilities here in golangci/golangci-lint#2438 (comment) with some high-level status for generics support, including red X's for "known to panic on generic code".

gopherjs/gopherjs#1013 is the specific issue that tracks Generics support in GopherJS.

@thepudds

Hi @findleyr One thing that might be helpful is a pointer to a body of generic Go code to test against?

The test cases in test/typeparam might be useful for that.

@thepudds thank you! Sorry for the slow turnaround: I will incorporate that list along with what I know about x/tools analyzers.

Regarding a corpus of generic code: @zephyrtronium's suggestion of test/typeparam is good. I also sometimes use go/types/testdata/examples. But the point stands: I think we should perhaps consider including a small corpus in the soon-to-be-created x/exp/typeparams module.

Due to golangci-lint v1.45.0 being released, I think its status is now supported.

Thanks @ipfans -- I updated to note that golangci-lint has partial generics support.

Regarding a corpus of generic code: @zephyrtronium's suggestion of test/typeparam is good. I also sometimes use go/types/testdata/examples. But the point stands: I think we should perhaps consider including a small corpus in the soon-to-be-created x/exp/typeparams module.

I was wondering what's the current status of this, if it has evolved :) I tried using go/types/testdata/examples, but it contains some /* ERROR ... */ lines, presumably failing to typecheck on purpose - so it's no good as-is as a generic code corpus for tools. I also found https://github.com/golang/exp/tree/master/typeparams/example, though it seems to be a collection of example tools, so it's not quite what I'm after either.

To give some more context: I'm after hundreds of lines of Go code, not thousands or tens of thousands, because that code will need to be copied to each of the modules for the tools which I need to ensure don't panic on e.g. unexpected go/ast nodes for generic code. I imagine that one wouldn't need that much code to represent most syntax and typechecking edge cases :)

Change https://go.dev/cl/402254 mentions this issue: go.mod: update to golang.org/x/text v0.1.10

@mvdan

I was wondering what's the current status of this, if it has evolved :)

No status change as far as I know, sorry. I think we'd welcome an addition to x/exp/typeparams. Perhaps the corpus should be available as an importable package within that module? Would that work for your purposes, or would you more likely make a copy?

I tried using go/types/testdata/examples, but it contains some /* ERROR ... */ lines, presumably failing to typecheck on purpose

Yes, those comments denote expected errors.

• so it's no good as-is as a generic code corpus for tools.

That depends on whether you want to test your tool in the presence of errors, I suppose, but your point stands. I think a good starting point for a corpus may be to filter out those error cases.

@findleyr very nits, but goa/goagen link url is now https://github.com/golang/go/issues/github.com/goadesign/goa/goagen.

@findleyr very nits, but goa/goagen link url is now https://github.com/golang/go/issues/github.com/goadesign/goa/goagen.

Thanks. That URL doesn't look right (it starts with github.com/golang...), but I updated the goagen URL based on a Google search. Please let me know if it's still not right.

@findleyr Thanks for fix.

But, I'm not familiar with goa, but goa seems to already released v3 using v3 default branch. Also gen move to subcommand.

• https://github.com/goadesign/goa#2-implement

So, I think correct URL is just:
https://github.com/goadesign/goa