This is a release-blocker for Go 1.16 via #11811.

So this error comes from this declaration:

// This is only here so that tests can refer to it.
type callbackArgRaw C.sqlite3_value

(It appears there is no use of this type in the current codebase, but that's not really relevant here.)

The type C.sqlite3_value is marked as go:notinheap because it is an incomplete type:

typedef struct sqlite3_value sqlite3_value;

That all looks correct. The actual implementation of sqlite3_value is indeed some sort of union-with-type-tag that can't be allocated faithfully in Go. Note that a pointer to a C.sqlite3_value is fine, they are real pointers (unlike #40954).

There's no real error in the user's code, because callbackArgRaw is never used in a way which would cause a heap allocation of that type. There is also a similar occurrence in misc/cgo/stdio/testdata/file.go where on Dragonfly the C.FILE type from stdio.h is also incomplete, so this declaration also fails with the same error:

type File C.FILE

This is making me think we need to silently propagate the go:notinheap-ness of types in their declarations. So if we have

//go:notinheap
type nih int

type T nih
type S struct { x nih }
type A [2]nih

Then types T, S, and A would all be implicitly notinheap as well. We won't produce an error for the user unless one of those types is used in a context which causes allocation. Uses of things like *T would be fine, though (which is the case for both of the issues discussed above).

@ianlancetaylor

Note that we already do this propagation for structs and arrays. It's only for named types that we don't propagate at the moment.

We propagate for named types also. We just also emit an error if a type has the notinheap mark but wasn't explicitly marked with a pragma. I think if we just get rid of that latter error, we should be ok.

Change https://golang.org/cl/255637 mentions this issue: cmd/compile: propagate go:notinheap implicitly

I agree that it makes sense to propagate notinheap status across defined types.

As far as I know at present only the runtime package uses notinheap, so the only question is whether that breaks anything in the runtime package.