Not just tests,

fails: https://go.dev/play/p/rM-aiRMn4rd

//go:debug panicnil=1
package main

func main() {
	panic(nil)
}

vs

passes: https://go.dev/play/p/BZY9qp1ilAI

//go:debug panicnil=1

package main

func main() {
	panic(nil)
}

cc @timothy-king

I suspect the directive analyzer handles //go:debug comments this way for consistency with //go:build comments, which are "ignored adjoining the package declaration":

		// A +build comment is ignored after or adjoining the package declaration.
		if group.End()+1 >= f.Package {
			check.inHeader = false
		}

Assigning to @rsc to adjudicate the desired behavior.

Change https://go.dev/cl/569360 mentions this issue: go/analysis/passes/directive: do not report adjoining //go:debug

//go:debug comments are parsed by the same code that parses //go:build comments. So the vet warning seems consistent.

That said, unless my testing is broken the parsing does currently permit the //go:build or //go:debug comment to appear as part of the package comment. The only requirement is that the comment appear before the package clause. That may be a bug.

@ianlancetaylor I don't interpret "(preceding the package statement)" on the documentation page on go:debug as requiring the comment having a newline between it and package main, but perhaps I'm misunderstanding what "package clause"/"package statement"/"package comment" means in this context? The spec makes no reference to requiring white space between any comment and the package clause, but I suppose this is a toolchain-specific question and not a spec one.

// +build comments need a blank line, because otherwise a package doc comment talking about the +build feature might
accidentally turn into a semantically important comment after an unfortunate line wrap.

Newer directives of the //tool:thing form do not need that blank line and do not have the wrapping problem. As part of the richer doc comment syntax, we updated gofmt and friends to move such directives to the end of doc comments and not to print them as documentation.

Empirically, new-style directives, both //go:debug and //go:build, are recognized in package doc comments:

% cat x.go
// Hello world
//
//go:debug panicnil=2
package main
% go list -f '{{.DefaultGODEBUG}}' x.go
panicnil=2
% 

% cat x.go
// Hello world
//go:build linux
package main
% gofmt x.go | gofmt
//go:build linux

// Hello world
//
package main
% 

Since the standard tools recognize them in the package doc comment, x/tools/go/analysis should recognize them there too. But be sure not to start recognizing // +build in the package doc comment.

It is possible that the code has always been wrong but it didn't matter because gofmt moves //go:build lines out of package doc comments into stanzas of their own. So it goes.