You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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).