I believe unsupported flags should be ignored

But this way the user would be misled into thinking they are testing with the race detector activated, when they're not.

Perhaps we could show a warning instead of an error? There's a precedent for non-fatal warning messages in the go tool.

Thinking outloud some more - what we want is a best-effort GOFLAGS. It kind of is like that already, since commands ignore flags they don't know about, like @eliasnaur said. We want to go a bit further and go past "unsupported" errors. If a user really wants to force the use of a flag, they could use go build -race, which will get the current behavior.

IMO there is a fundamental difference between

• This flag is not known to us
• It does not make sense to enable this flag -which yes, we do support- in this specific configuration

Consider the following (which currently errors):

$ GOFLAGS="-buildmode=pie -race" go build test.go

-buildmode=pie not supported when -race is enabled

Which one do we ignore? We build with pie and ignore -race? Or we build with -race and ignore pie? Or we ignore both and we build a non-race, non-pie binary?

It seems to me that this could get confusing quickly, from a UX point of view.

You raise a good point. Treating -race especially within GOFLAGS could add complexity too.

For what it's worth, we made it so that the test that builds with GOOS=js skips itself when the race tag is enabled. Detecting the build tag requires a global bool and an extra file, but the setup is simple enough.