crypto: use purego tag consistently

[FiloSottile]

We've been inconsistent in using the purego tag in the standard library because it was not clear what would be its use aside from letting me benchmark assembly vs native code. I noticed on the Gophers Slack that tagging purego consistently would probably make TinyGo's life easier when trying to compile crypto packages, and presumably any other Go compiler. https://tinygo.org/docs/reference/lang-support/stdlib/#crypto

It's easy enough to do, so why not. Might also add a purego compilation test of crypto/... to longtest.

/cc @dgryski

[dgryski]

The hash/crc32 package also needs purego tags.

[cuonglm]

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.

[gopherbot]

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

[gopherbot]

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

[aykevl]

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

[FiloSottile]

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".

[aykevl]

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.