Repository: go
Issue: go/types: error "type instantiation requires go1.18 or later" is unclear when go version comes from go.mod
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.18.2 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
1.18.2 is the latest at the time of writing; I have not tried on tip/other branches or versions.


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/iburton/.cache/go-build"
GOENV="/home/iburton/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/iburton/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=//elided
GOOS="linux"
GOPATH="/home/iburton/go"
GOPRIVATE=""
GOPROXY=//elided
GOROOT="/home/iburton/.gvm/versions/go1.18.2.linux.amd64"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/iburton/.gvm/versions/go1.18.2.linux.amd64/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18.2"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=//elided
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3437891855=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->
Working in a module that specifies 1.16 as minimum, tried adding a file with
`//go:build go1.18`
For a file that should only be built/included when go1.18 or newer is used.


### What did you expect to see?
The build and my editor (vscode + gopls) to work and not fail


### What did you see instead?
type instantiation requires go1.18 or later compiler[UnsupportedFeature](https://pkg.go.dev/golang.org/x/tools/internal/typesinternal?utm_source%3Dgopls#UnsupportedFeature)

### Context
Well I had an entirely different bug report written until just before I submitted it when I realized what I think is a documentation issue.
The TLDR on the issue was I had a module with `go 1.16` and wanted to add some code/files that used generics **guarded by a build flag** such as mentioned:

From [cmd/go](https://pkg.go.dev/cmd/go#hdr-Build_constraints)
>During a particular build, the following words are satisfied: 
>- a term for each Go major release, through the current version:
  "go1.1" from Go version 1.1 onward, "go1.12" from Go 1.12, and so on.
  
With the above error from gopls/go build when I used generics, _but not when I stopped using them (and left the 1.18 restriction)_ I thought this was a bug until I finally found a line in the [module reference](https://go.dev/ref/mod#go-mod-file-go)
>For packages within the module, the compiler rejects use of language features introduced after the version specified by the go directive. For example, if a module has the directive go 1.12, its packages may not use numeric literals like 1_000_000, which were introduced in Go 1.13.

I'm not sure why it isn't allowed if such a file is guarded with build flag/constraints (the module reference doesn't mention those at all). But I'm assuming this is the cause of what I'm seeing. I had looked at the 1.18 release notes, the generics proposal, go/build, `go help build` and various other places and didn't find anything mentioning the disabling of features like this, other than in the module ref above. It was obvious to me code using or expecting to work with 1.16 would not work with generics or any language feature introduced after, **but** if such code lives in a separate file that is guarded (just like you'd do for anything else say based on OS or ARCH) I didn't understand why that wasn't working.

Perhaps more documentation can be added to go/build and cmd friends that mentions this? And maybe a better error if this comes up, something like:
> X language feature cannot be used due to go directive in go.mod, Go version build flags included, see 'go help build' or 'go help mod' for more information

While I'm at it, if the use of a language feature is guarded with flags why not allow its use? If I have a module that says 1.16 is the minimum but code _in its own file that won't be included in a 1.16 build_ why not allow the (rest of the module) code to still build? Perhaps there was a good reason or maybe build flags based on Go version were over looked relative to this module (compiler?) restriction? I don't want to move the entire module to 1.18 for a relatively small bit of optional code, for the time being, so using a build flag I thought was the proper solution.

Thank you!