The hash/crc32 package also needs purego tags.

FYI, the purego proposal is accepted #23172

I also had https://go-review.googlesource.com/c/go/+/468795, which implements a purego version of hash/maphash. There, you can add the test with purego tag in cmd/dist.

Change https://go.dev/cl/561935 mentions this issue: crypto: use and test purego tag consistently

Change https://go.dev/cl/561955 mentions this issue: TargetSpecific: update purego tag guidance

To be clear, purego means "use Go instead of assembly"?
I'm asking, because it could also be interpreted as "don't use CGo". In TinyGo we do support CGo (with some limitations) but Go assembly is very difficult due to the special syntax and different calling convention. So basically we'd like to set the purego tag by default to avoid assembly but would still like to use CGo.

In #23172 it seems that purego is defined as "no assembly, unsafe, or CGo", which combines a number of unrelated features and would not fit very well with TinyGo.

It's probably much too late to change, but noasm would be a much better fit for TinyGo because it's more explicit (and similarly, nounsafe could be used - for CGo we already have the cgo build tag).

Related: tinygo-org/tinygo#4116

To be clear, purego means "use Go instead of assembly"? I'm asking, because it could also be interpreted as "don't use CGo". In TinyGo we do support CGo (with some limitations) but Go assembly is very difficult due to the special syntax and different calling convention. So basically we'd like to set the purego tag by default to avoid assembly but would still like to use CGo.

In #23172 it seems that purego is defined as "no assembly, unsafe, or CGo", which combines a number of unrelated features and would not fit very well with TinyGo.

Indeed, it might be a bit coarse, but I think purego means "no assembly, unsafe, or cgo when there is a pure-Go alternative". There's no point making a build tag for breaking a build. So in practice it mostly means "no assembly" and only occasionally "no unsafe".

Hmm, that's unfortunate. I imagine it could limit features/performance in some cases now that we use purego by default.

For CGo, I'd normally assume the cgo build tag would be used. That's the build tag specifically meant for that purpose as far as I know. While TinyGo doesn't support all CGo features, it's pretty close and missing parts are generally not too difficult to add.
TinyGo does support unsafe just fine though. It has a different memory layout for some types, but portable code would try to avoid relying on a specific memory layout anyway.