Skip to content
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

x/pkgsite: add support for type parameters #48264

Open
findleyr opened this issue Sep 8, 2021 · 3 comments
Open

x/pkgsite: add support for type parameters #48264

findleyr opened this issue Sep 8, 2021 · 3 comments

Comments

@findleyr
Copy link
Contributor

@findleyr findleyr commented Sep 8, 2021

As the proposal for go/ast has stabilized (#47781), I think it is time to start adding support for type parameters in pkgsite.

There is one major obstacle for this, which is that App Engine will not support 1.18 until some time after the 1.18 release, and we want to support type parameters well before then.

My thoughts on how to do this:

  • Write a tool to maintain copies of stdlib packages in pkgsite. I made a working prototype of this in https://golang.org/cl/322411
  • Copy the following packages to pkgsite: go/ast, go/build/constraint, go/format, go/internal/typeparams, go/parser, go/token, go/printer, go/scanner.
  • Wire these in to pkgsite, which already uses a modified copy of go/doc.

I tested that this was possible in https://golang.org/cl/321949.

Once this is done, we should be able to sync these copied packages to tip using go generate. Out of the box this should resolve parsing errors for generic code, and we can proceed with adding any additional features that make it easier to browse code with type parameters in pkgsite. After App Engine supports 1.18, we can delete these copies.

I can do this, but will hold of for a week or two to see if anyone has concerns or better ideas.

CC @julieqiu @jba @jamalc

@findleyr findleyr self-assigned this Sep 8, 2021
@findleyr findleyr added this to the Go1.18 milestone Sep 8, 2021
@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Sep 8, 2021

I understand the scope of this issue is x/pkgsite, and I don't mean to change that.

I'll point out that a similar issue may apply to x/website, though golang.org serves documentation under a significantly reduced set of use cases as of #44356. It similarly has a directory with ported stdlib packages (https://go.googlesource.com/website/+/refs/heads/master/internal/backport/).

@jba
Copy link
Contributor

@jba jba commented Sep 9, 2021

I'm in favor. There is an alternative: move pkgsite to Cloud Run. That would probably be more work, and certainly more risk, but I just wanted to put it out there.

One point you don't mention: none of those packages would be able to use 1.18 features (including generics) for a while. And we won't know that they do until we copy them and recompile pkgsite. On the other hand, I don't imagine they'll change much once generics are done.

@findleyr
Copy link
Contributor Author

@findleyr findleyr commented Sep 9, 2021

One point you don't mention: none of those packages would be able to use 1.18 features

Right, that's a good point. In https://golang.org/cl/321949 I had to add a stub io/fs for this reason.

IIRC @griesemer and I had discussed and thought this was OK for these packages in particular. We also have a history of maintaining ports like x/tools/go/internal/gcimporter, but that's more work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants