CL https://golang.org/cl/34561 mentions this issue.

Doing it for all go code looks easier. Tricky part is limiting this to runtime.

There is a flag that gets passed to the compiler when compiling the runtime, so it should be straightforward. On my phone, but look for a variable in cmd/compile/internal/gc called something like compiling_runtime. :)

Limiting to just std is harder, but one option is to add a new compiler flag to validate //go: comments, and have cmd/go pass it iff the package is in std.

That would also help with testing, I suspect.

CL https://golang.org/cl/34562 mentions this issue.

I've taken a stab at this with https://go-review.googlesource.com/34562 as my afternoon project.
For starters am doing a simple check if code is in $GOROOT to detect if it is stdlib code or if compiling_runtime, and
then from there validate if a pragma verb is known.

@Dhananjay92 I was using my phone to get notifications about issues. Now I see that our CLs are both up to solve the same issue. Sure, let's coordinate on yours. I'll tag @josharian and @mdempsky as reviewers on your CL.

Yes, we should limit this check somehow to our code. I am waiting for us to reach some decision on whether to take an extra flag enabling this check, or try to deduce that with the help of compiling_runtime.

So what does everyone think, should we take an extra flag or limit to only when compiling_runtime==true?

Also, if we care about these in our repository only, why not implement this in a static checker, like govet?

We've also had to fix instances where go: comments were line-wrapped elsewhere into a paragraph, so they were no longer treated as pragmas: golang.org/cl/12271. Not sure if that's something we can/want to try addressing at the same time.

Also, if we care about these in our repository only, why not implement this in a static checker, like govet?

Or in the Go repo's commit hook?

Also, if we care about these in our repository only, why not implement this in a static checker, like govet?

We discussed this a bit on https://golang.org/cl/34378. The problem with govet is that we basically never run it on the runtime because it's incredibly noisy (the runtime has to do all sorts of things govet doesn't like).

There are already several other runtime-specific checks in the compiler. Though AFAIK there are no std-specific checks.

The problem with govet is that we basically never run it on the runtime because it's incredibly noisy.

Actually, I spent a fair amount of time in the 1.8 cycle writing a vet runner with whitelists specifically so that we could run vet on std and cmd (and in the process fixed a lot of bugs in vet and std/cmd). However, it never got a builder set up for it, and it regressed almost every day. Evidence of its value, I suppose. Around the beginning of the freeze I stopped trying to keep up. When there is a builder set up for it (in Brad's court, AFAIK), we can do one more big push to get everything cleaned up and make it green and include it in the trybots. And at that point, we could rely on vet or a vet-like check.

AFAIK there are no std-specific checks.

As I mentioned above, if we wanted to do something like this for std in the compiler, I'd suggest adding a compiler flag specifically to check this, and then arrange for cmd/go to send it into the compiler when compiling std. This is good for testing, and others who use magic go comments could also add it to their own gcflags.

CL https://golang.org/cl/45010 mentions this issue.