-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
tools: track tools/tooling updates to support generics #50558
Comments
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. |
Whoops! I started with the list from #24661, and missed that link. I removed the gogrep item, and marked gofumpt as done. Thanks! |
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. |
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 Regarding a corpus of generic code: @zephyrtronium's suggestion of |
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. |
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 |
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 |
Change https://go.dev/cl/402254 mentions this issue: |
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?
Yes, those comments denote expected errors.
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. |
go get -u golang.org/x/tools go mod tidy For golang/go#50558 Fixes golang/go#52552 Change-Id: I233aa90922fc23800563fd05beb4be6f7e87cf5b Reviewed-on: https://go-review.googlesource.com/c/text/+/402254 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>
@findleyr very nits, but goa/goagen link url is now |
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 So, I think correct URL is just: |
go get -u golang.org/x/tools go mod tidy For golang/go#50558 Fixes golang/go#52552 Change-Id: I233aa90922fc23800563fd05beb4be6f7e87cf5b Reviewed-on: https://go-review.googlesource.com/c/text/+/402254 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>
Many tools and libraries that operate on Go code need to be updated to support generics. In most cases, this requires handling of the new constructs introduced in
go/ast
andgo/types
.This is a tracking issue for the status of this support. It is based on #24661, which did the same for modules, though I added several tools/packages, and removed any that have been archived or that don't work directly with Go code.
It is not the case that every tool listed here needs updates to support generics -- many will require no changes. However, any tool that interacts with Go code might need to be updated, and probably needs additional tests.
Issue #50447 tracks adding a transitional API + user guide that should make it easier to get started updating third-party tools.
How to Help
List of tools / packages
gopls
go-langserver- usegopls
insteadgo-outline
withgopls
vscode-go#1020 for implementing this functionality in goplsgocode- replaced bygopls
gopls
gopls
gopls
gopls
gomodifytags
functionality intogopls
and usegopls
vscode-go#2002 for merging this functionality with gopls)gopls
x/tools/cmd/godoc- replaced by pkgsitegopls
gopls
x/tools/cmd/guru- replaced bygopls
x/tools/go/loader- Deprecated: replaced by go/packagesThe text was updated successfully, but these errors were encountered: