doc/go1.17.html | 62 +++++++++++++++++++++++++++++++---------------------- src/crypto/tls/key_agreement.go | 6 +++++- src/runtime/pprof/mprof_test.go | 11 +++++++++++ diff --git a/doc/go1.17.html b/doc/go1.17.html index 4fa30158bb2d49f543cb80e37301917d1272b2bd..fa8f14de99d553f1b6f57729176fd451dabf69bb 100644 --- a/doc/go1.17.html +++ b/doc/go1.17.html @@ -401,30 +401,37 @@

Compiler

Go 1.17 implements a new way of passing function arguments and results using - registers instead of the stack. This work is enabled for Linux, macOS, and - Windows on the 64-bit x86 architecture (the linux/amd64, - darwin/amd64, windows/amd64 ports). For a - representative set of Go packages and programs, benchmarking has shown - performance improvements of about 5%, and a typical reduction in binary size - of about 2%. + registers instead of the stack. + Benchmarks for a representative set of Go packages and programs show + performance improvements of about 5%, and a typical reduction in + binary size of about 2%. + This is currently enabled for Linux, macOS, and Windows on the + 64-bit x86 architecture (the linux/amd64, + darwin/amd64, and windows/amd64 ports).

- This change does not affect the functionality of any safe Go code. It can affect - code outside the compatibility guidelines with - minimal impact. To maintain compatibility with existing assembly functions, - adapter functions converting between the new register-based calling convention - and the previous stack-based calling convention (also known as ABI wrappers) - are sometimes used. This is mostly invisible to users, except for assembly - functions that have their addresses taken in Go. Using reflect.ValueOf(fn).Pointer() - (or similar approaches such as via unsafe.Pointer) to get the address - of an assembly function will now return the address of the ABI wrapper. This is - mostly harmless, except for special-purpose assembly code (such as accessing - thread-local storage or requiring a special stack alignment). Assembly functions - called indirectly from Go via func values will now be made through - ABI wrappers, which may cause a very small performance overhead. Also, calling - Go functions from assembly may now go through ABI wrappers, with a very small - performance overhead. + This change does not affect the functionality of any safe Go code + and is designed to have no impact on most assembly code. + It may affect code that violates + the unsafe.Pointer + rules when accessing function arguments, or that depends on + undocumented behavior involving comparing function code pointers. + To maintain compatibility with existing assembly functions, the + compiler generates adapter functions that convert between the new + register-based calling convention and the previous stack-based + calling convention. + These adapters are typically invisible to users, except that taking + the address of a Go function in assembly code or taking the address + of an assembly function in Go code + using reflect.ValueOf(fn).Pointer() + or unsafe.Pointer will now return the address of the + adapter. + Code that depends on the value of these code pointers may no longer + behave as expected. + Adapters also may cause a very small performance overhead in two + cases: calling an assembly function indirectly from Go via + a func value, and calling Go functions from assembly.

@@ -440,11 +447,14 @@ printed.

- Functions containing closures can now be inlined. One effect of this change is - that a function with a closure may actually produce a distinct closure function - for each place that the function is inlined. Hence, this change could reveal - bugs where Go functions are compared (incorrectly) by pointer value. Go - functions are by definition not comparable. + Functions containing closures can now be inlined. + One effect of this change is that a function with a closure may + produce a distinct closure code pointer for each place that the + function is inlined. + Go function values are not directly comparable, but this change + could reveal bugs in code that uses reflect + or unsafe.Pointer to bypass this language restriction + and compare functions by code pointer.

Core library

diff --git a/src/crypto/tls/key_agreement.go b/src/crypto/tls/key_agreement.go index 8cfbd734f15f22c372a439ee218f3bbb12842a42..c28a64f3a8b8c5a2eeae3f62cee7966cf7b7a4d4 100644 --- a/src/crypto/tls/key_agreement.go +++ b/src/crypto/tls/key_agreement.go @@ -86,7 +86,11 @@ if err != nil { return nil, nil, err } - encrypted, err := rsa.EncryptPKCS1v15(config.rand(), cert.PublicKey.(*rsa.PublicKey), preMasterSecret) + rsaKey, ok := cert.PublicKey.(*rsa.PublicKey) + if !ok { + return nil, nil, errors.New("tls: server certificate contains incorrect key type for selected ciphersuite") + } + encrypted, err := rsa.EncryptPKCS1v15(config.rand(), rsaKey, preMasterSecret) if err != nil { return nil, nil, err } diff --git a/src/runtime/pprof/mprof_test.go b/src/runtime/pprof/mprof_test.go index 3ef40d3de7de1c52f0de642257320840a2071f18..b4680fbdee99ecb6c79a32e6e591745ec2664175 100644 --- a/src/runtime/pprof/mprof_test.go +++ b/src/runtime/pprof/mprof_test.go @@ -86,6 +86,17 @@ memSink = nil runtime.GC() // materialize stats + // TODO(mknyszek): Fix #45315 and remove this extra call. + // + // Unfortunately, it's possible for the sweep termination condition + // to flap, so with just one runtime.GC call, a freed object could be + // missed, leading this test to fail. A second call reduces the chance + // of this happening to zero, because sweeping actually has to finish + // to move on to the next GC, during which nothing will happen. + // + // See #46500 for more details. + runtime.GC() + memoryProfilerRun++ tests := []struct {