x/pkgsite: support showing identifiers that are constrained by build tags

[codyoss]

What did you do?

• I created a commit that added a new function to a module in a file constrained by // +build preview: codyoss/foo@cd688cd
• I published a new module version that contained this commit: https://github.com/codyoss/foo/releases/tag/v0.2.0
• I went to https://pkg.go.dev/github.com/codyoss/foo@v0.2.0 to see my see the docs I wrote for my function.

What did you expect to see?

I expect some way to view docs for identifiers that are guarded by build constraints and the file to be listed is source files. Maybe something similar to how the official language docs can call out what version of Go an identifier was added in or a dropdown to select constraints? This could also be useful if a Windows version of a function has slightly different docs than the linux version.

What did you see instead?

I could not view the docs for my constrained function. Nor could I see constrained.go in the list of Source Files.

Additional context

This is sort of an off-shoot of some of the chatter in #34409. A suggestion was made to hide identifiers with build constraints. To me this would only be viable if developers could see those identifiers in documentation easily.

[ianlancetaylor]

CC @julieqiu

[julieqiu]

We do support a few common build tags for GOOS/GOARCH, but not arbitrary tags. This was discussed in #37232.

[rsc]

The proposal process is for "any notable change or addition to the language, libraries and tools", largely because once we ship them, we can't take them back. We have to make sure we get to things we are comfortable with for at least the next decade or so.

This isn't true of pkgsite, so pkgsite issues need not be in the proposal process.

Spoke to @julieqiu about this one and she said that GOOS/GOARCH are handled and that probably arbitrary build tags are too much work for too little benefit, but I will leave it to her to close.

Removing from proposal bins.

[jba]

Going to close this. Reopen if there is something new here not covered in #37232.