3 ms·

I agreed with jeffsmith82's comment.

• zaarn 6y ago
  That comment isn't applicable either; I had x/crypto vendored so any fix upstream wouldn't break my app.
  • Aissen 6y ago
    I'm afraid blake2 used assembly and runtime.support_avx2, which doesn't seem to be covered by the compatibility promise: assembly is part of the toolchain, and the symbol it used was an internal one. See: https://go-review.googlesource.com/c/crypto/+/110355/ https://go-review.googlesource.com/c/crypto/+/110355/ https://go-review.googlesource.com/c/crypto/+/110016/ https://go-review.googlesource.com/c/crypto/+/110016/
    • zaarn 6y ago
      So, my code broke because a library that was provided by the go developers used some unstable feature I had no idea about and had no real way of knowing short of checking a dependency three levels below my project? And to top that, that library was certainly subject to API breakage, the entire reason I vendored it in the first place. It doesn't seem reasonable to me. When I developed my project, vendoring /x/ projects was recommended exactly due to the breakage, so now it breaks my projects because of recommendations of the golang team.