3 ms·

One of those point under "Expectations" can be explain in this page https://golang.org/doc/go1compat https://golang.org/doc/go1compat

zaarn 6y ago
Nope, none of these points apply to the specific change, atleast as far as I am able to tell. The code that broke did not use unsafe when I last updated it and then it simply didn't work anymore in the current go version.
- deleted 6y ago
  [deleted]
- todotask 6y ago
  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.
- TheDong 6y ago
  I believe one of those probably applies. > Use of package unsafe. Packages that import unsafe may depend on internal properties of the Go implementation. We reserve the right to make changes to the implementation that may break such programs. I suspect the crypto code you vendored used unsafe somewhere within it (whether to use `//go:linkname` or for other reasons), which would except it from the go1 compatibility promise.

zaarn 6y ago

Nope, none of these points apply to the specific change, atleast as far as I am able to tell. The code that broke did not use unsafe when I last updated it and then it simply didn't work anymore in the current go version.

deleted 6y ago
[deleted]
todotask 6y ago
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.
TheDong 6y ago
I believe one of those probably applies. > Use of package unsafe. Packages that import unsafe may depend on internal properties of the Go implementation. We reserve the right to make changes to the implementation that may break such programs. I suspect the crypto code you vendored used unsafe somewhere within it (whether to use `//go:linkname` or for other reasons), which would except it from the go1 compatibility promise.