Update to go1.25.0

This commit is contained in:
Vorapol Rinsatitnon
2025-08-13 21:50:03 +07:00
parent 4fdddd398d
commit c7759f4edb
2303 changed files with 161699 additions and 70952 deletions

File diff suppressed because it is too large Load Diff

View File

@@ -453,7 +453,7 @@ crash, or do something else.)
</p>
<p class="rule">
The <i>k</i>th receive on a channel with capacity <i>C</i> is synchronized before the completion of the <i>k</i>+<i>C</i>th send from that channel completes.
The <i>k</i>th receive from a channel with capacity <i>C</i> is synchronized before the completion of the <i>k</i>+<i>C</i>th send on that channel.
</p>
<p>

View File

@@ -1,6 +1,6 @@
<!--{
"Title": "The Go Programming Language Specification",
"Subtitle": "Language version go1.24 (Dec 30, 2024)",
"Subtitle": "Language version go1.25 (Feb 25, 2025)",
"Path": "/ref/spec"
}-->
@@ -8,8 +8,6 @@
<p>
This is the reference manual for the Go programming language.
The pre-Go1.18 version, without generics, can be found
<a href="/doc/go1.17_spec.html">here</a>.
For more information and other documents, see <a href="/">go.dev</a>.
</p>
@@ -1858,110 +1856,10 @@ The underlying type of <code>[]B1</code>, <code>B3</code>, and <code>B4</code> i
The underlying type of <code>P</code> is <code>interface{}</code>.
</p>
<h3 id="Core_types">Core types</h3>
<p>
Each non-interface type <code>T</code> has a <i>core type</i>, which is the same as the
<a href="#Underlying_types">underlying type</a> of <code>T</code>.
</p>
<p>
An interface <code>T</code> has a core type if one of the following
conditions is satisfied:
</p>
<ol>
<li>
There is a single type <code>U</code> which is the <a href="#Underlying_types">underlying type</a>
of all types in the <a href="#Interface_types">type set</a> of <code>T</code>; or
</li>
<li>
the type set of <code>T</code> contains only <a href="#Channel_types">channel types</a>
with identical element type <code>E</code>, and all directional channels have the same
direction.
</li>
</ol>
<p>
No other interfaces have a core type.
</p>
<p>
The core type of an interface is, depending on the condition that is satisfied, either:
</p>
<ol>
<li>
the type <code>U</code>; or
</li>
<li>
the type <code>chan E</code> if <code>T</code> contains only bidirectional
channels, or the type <code>chan&lt;- E</code> or <code>&lt;-chan E</code>
depending on the direction of the directional channels present.
</li>
</ol>
<p>
By definition, a core type is never a <a href="#Type_definitions">defined type</a>,
<a href="#Type_parameter_declarations">type parameter</a>, or
<a href="#Interface_types">interface type</a>.
</p>
<p>
Examples of interfaces with core types:
</p>
<pre>
type Celsius float32
type Kelvin float32
interface{ int } // int
interface{ Celsius|Kelvin } // float32
interface{ ~chan int } // chan int
interface{ ~chan int|~chan&lt;- int } // chan&lt;- int
interface{ ~[]*data; String() string } // []*data
</pre>
<p>
Examples of interfaces without core types:
</p>
<pre>
interface{} // no single underlying type
interface{ Celsius|float64 } // no single underlying type
interface{ chan int | chan&lt;- string } // channels have different element types
interface{ &lt;-chan int | chan&lt;- int } // directional channels have different directions
</pre>
<p>
Some operations (<a href="#Slice_expressions">slice expressions</a>,
<a href="#Appending_and_copying_slices"><code>append</code> and <code>copy</code></a>)
rely on a slightly more loose form of core types which accept byte slices and strings.
Specifically, if there are exactly two types, <code>[]byte</code> and <code>string</code>,
which are the underlying types of all types in the type set of interface <code>T</code>,
the core type of <code>T</code> is called <code>bytestring</code>.
</p>
<p>
Examples of interfaces with <code>bytestring</code> core types:
</p>
<pre>
interface{ int } // int (same as ordinary core type)
interface{ []byte | string } // bytestring
interface{ ~[]byte | myString } // bytestring
</pre>
<p>
Note that <code>bytestring</code> is not a real type; it cannot be used to declare
variables or compose other types. It exists solely to describe the behavior of some
operations that read from a sequence of bytes, which may be a byte slice or a string.
</p>
<h3 id="Type_identity">Type identity</h3>
<p>
Two types are either <i>identical</i> or <i>different</i>.
Two types are either <i>identical</i> ("the same") or <i>different</i>.
</p>
<p>
@@ -3255,7 +3153,8 @@ math.Sin // denotes the Sin function in package math
<h3 id="Composite_literals">Composite literals</h3>
<p>
Composite literals construct new composite values each time they are evaluated.
Composite literals construct new values for structs, arrays, slices, and maps
each time they are evaluated.
They consist of the type of the literal followed by a brace-bound list of elements.
Each element may optionally be preceded by a corresponding key.
</p>
@@ -3273,10 +3172,14 @@ Element = Expression | LiteralValue .
</pre>
<p>
The LiteralType's <a href="#Core_types">core type</a> <code>T</code>
Unless the LiteralType is a type parameter,
its <a href="#Underlying_types">underlying type
must be a struct, array, slice, or map type
(the syntax enforces this constraint except when the type is given
as a TypeName).
If the LiteralType is a type parameter, all types in its type set
must have the same underlying type which must be
a valid composite literal type.
The types of the elements and keys must be <a href="#Assignability">assignable</a>
to the respective field, element, and key types of type <code>T</code>;
there is no additional conversion.
@@ -3461,7 +3364,6 @@ noteFrequency := map[string]float32{
}
</pre>
<h3 id="Function_literals">Function literals</h3>
<p>
@@ -3934,11 +3836,12 @@ The following rules apply:
</p>
<p>
If <code>a</code> is neither a map nor a type parameter:
If <code>a</code> is neither a map nor a <a href="#Type_parameter_declarations">type parameter</a>:
</p>
<ul>
<li>the index <code>x</code> must be an untyped constant or its
<a href="#Core_types">core type</a> must be an <a href="#Numeric_types">integer</a></li>
<li>the index <code>x</code> must be an untyped constant, or its type must be
an <a href="#Numeric_types">integer</a> or a type parameter whose type set
contains only integer types</li>
<li>a constant index must be non-negative and
<a href="#Representability">representable</a> by a value of type <code>int</code></li>
<li>a constant index that is untyped is given type <code>int</code></li>
@@ -4052,14 +3955,26 @@ Assigning to an element of a <code>nil</code> map causes a
<p>
Slice expressions construct a substring or slice from a string, array, pointer
to array, or slice. There are two variants: a simple form that specifies a low
to array, or slice operand.
There are two variants: a simple form that specifies a low
and high bound, and a full form that also specifies a bound on the capacity.
</p>
<p>
If the operand type is a <a href="#Type_parameter_declarations">type parameter</a>,
unless its type set contains string types,
all types in the type set must have the same underlying type, and the slice expression
must be valid for an operand of that type.
If the type set contains string types it may also contain byte slices with underlying
type <code>[]byte</code>.
In this case, the slice expression must be valid for an operand of <code>string</code>
type.
</p>
<h4>Simple slice expressions</h4>
<p>
The primary expression
For a string, array, pointer to array, or slice <code>a</code>, the primary expression
</p>
<pre>
@@ -4067,9 +3982,7 @@ a[low : high]
</pre>
<p>
constructs a substring or slice. The <a href="#Core_types">core type</a> of
<code>a</code> must be a string, array, pointer to array, slice, or a
<a href="#Core_types"><code>bytestring</code></a>.
constructs a substring or slice.
The <i>indices</i> <code>low</code> and
<code>high</code> select which elements of operand <code>a</code> appear
in the result. The result has indices starting at 0 and length equal to
@@ -4149,7 +4062,7 @@ s3 := s[:0] // s3 == nil
<h4>Full slice expressions</h4>
<p>
The primary expression
For an array, pointer to array, or slice <code>a</code> (but not a string), the primary expression
</p>
<pre>
@@ -4160,8 +4073,6 @@ a[low : high : max]
constructs a slice of the same type, and with the same length and elements as the simple slice
expression <code>a[low : high]</code>. Additionally, it controls the resulting slice's capacity
by setting it to <code>max - low</code>. Only the first index may be omitted; it defaults to 0.
The <a href="#Core_types">core type</a> of <code>a</code> must be an array, pointer to array,
or slice (but not a string).
After slicing the array <code>a</code>
</p>
@@ -4267,8 +4178,8 @@ No <a href="#Run_time_panics">run-time panic</a> occurs in this case.
<h3 id="Calls">Calls</h3>
<p>
Given an expression <code>f</code> with a <a href="#Core_types">core type</a>
<code>F</code> of <a href="#Function_types">function type</a>,
Given an expression <code>f</code> of <a href="#Function_types">function type</a>
<code>F</code>,
</p>
<pre>
@@ -4298,6 +4209,12 @@ If <code>f</code> denotes a generic function, it must be
or used as a function value.
</p>
<p>
If the type of <code>f</code> is a <a href="#Type_parameter_declarations">type parameter</a>,
all types in its type set must have the same underlying type, which must be a function type,
and the function call must be valid for that type.
</p>
<p>
In a function call, the function value and arguments are evaluated in
<a href="#Order_of_evaluation">the usual order</a>.
@@ -4811,17 +4728,28 @@ more complicated:
<ul>
<li>
If <code>C</code> has a <a href="#Core_types">core type</a>
<code>core(C)</code>
If all types in <code>C</code>'s type set have the same
underlying type <code>U</code>,
and <code>P</code> has a known type argument <code>A</code>,
<code>core(C)</code> and <code>A</code> must unify loosely.
<code>U</code> and <code>A</code> must unify loosely.
</li>
<li>
Similarly, if all types in <code>C</code>'s type set are
channel types with the same element type and non-conflicting
channel directions,
and <code>P</code> has a known type argument <code>A</code>,
the most restrictive channel type in <code>C</code>'s type
set and <code>A</code> must unify loosely.
</li>
<li>
If <code>P</code> does not have a known type argument
and <code>C</code> contains exactly one type term <code>T</code>
that is not an underlying (tilde) type, unification adds the
mapping <code>P ➞ T</code> to the map.
</li>
<li>
If <code>C</code> does not have a core type
If <code>C</code> does not have a type <code>U</code>
as described above
and <code>P</code> has a known type argument <code>A</code>,
<code>A</code> must have all methods of <code>C</code>, if any,
and corresponding method types must unify exactly.
@@ -5372,10 +5300,10 @@ var x *int = nil
<h3 id="Receive_operator">Receive operator</h3>
<p>
For an operand <code>ch</code> whose <a href="#Core_types">core type</a> is a
<a href="#Channel_types">channel</a>,
For an operand <code>ch</code> of <a href="#Channel_types">channel type</a>,
the value of the receive operation <code>&lt;-ch</code> is the value received
from the channel <code>ch</code>. The channel direction must permit receive operations,
from the channel <code>ch</code>.
The channel direction must permit receive operations,
and the type of the receive operation is the element type of the channel.
The expression blocks until a value is available.
Receiving from a <code>nil</code> channel blocks forever.
@@ -5391,6 +5319,12 @@ f(&lt;-ch)
&lt;-strobe // wait until clock pulse and discard received value
</pre>
<p>
If the operand type is a <a href="#Type_parameter_declarations">type parameter</a>,
all types in its type set must be channel types that permit receive operations, and
they must all have the same element type, which is the type of the receive operation.
</p>
<p>
A receive expression used in an <a href="#Assignment_statements">assignment statement</a> or initialization of the special form
</p>
@@ -6126,8 +6060,7 @@ len("foo") // illegal if len is the built-in function
<p>
A send statement sends a value on a channel.
The channel expression's <a href="#Core_types">core type</a>
must be a <a href="#Channel_types">channel</a>,
The channel expression must be of <a href="#Channel_types">channel type</a>,
the channel direction must permit send operations,
and the type of the value to be sent must be <a href="#Assignability">assignable</a>
to the channel's element type.
@@ -6151,6 +6084,13 @@ A send on a <code>nil</code> channel blocks forever.
ch &lt;- 3 // send value 3 to channel ch
</pre>
<p>
If the type of the channel expression is a
<a href="#Type_parameter_declarations">type parameter</a>,
all types in its type set must be channel types that permit send operations,
they must all have the same element type,
and the type of the value to be sent must be assignable to that element type.
</p>
<h3 id="IncDec_statements">IncDec statements</h3>
@@ -6743,8 +6683,7 @@ RangeClause = [ ExpressionList "=" | IdentifierList ":=" ] "range" Expression .
<p>
The expression on the right in the "range" clause is called the <i>range expression</i>,
its <a href="#Core_types">core type</a> must be
an array, pointer to an array, slice, string, map, channel permitting
which may be an array, pointer to an array, slice, string, map, channel permitting
<a href="#Receive_operator">receive operations</a>, an integer, or
a function with specific signature (see below).
As with an assignment, if present the operands on the left must be
@@ -6958,6 +6897,12 @@ for k, v := range t.Walk {
}
</pre>
<p>
If the type of the range expression is a <a href="#Type_parameter_declarations">type parameter</a>,
all types in its type set must have the same underlying type and the range expression must be valid
for that type, or, if the type set contains channel types, it must only contain channel types with
identical element types, and all channel types must permit receive operations.
</p>
<h3 id="Go_statements">Go statements</h3>
@@ -7431,23 +7376,28 @@ by the arguments overlaps.
<p>
The <a href="#Function_types">variadic</a> function <code>append</code>
appends zero or more values <code>x</code> to a slice <code>s</code>
and returns the resulting slice of the same type as <code>s</code>.
The <a href="#Core_types">core type</a> of <code>s</code> must be a slice
of type <code>[]E</code>.
appends zero or more values <code>x</code> to a slice <code>s</code> of
type <code>S</code> and returns the resulting slice, also of type
<code>S</code>.
The values <code>x</code> are passed to a parameter of type <code>...E</code>
where <code>E</code> is the element type of <code>S</code>
and the respective <a href="#Passing_arguments_to_..._parameters">parameter
passing rules</a> apply.
As a special case, if the core type of <code>s</code> is <code>[]byte</code>,
<code>append</code> also accepts a second argument with core type
<a href="#Core_types"><code>bytestring</code></a> followed by <code>...</code>.
This form appends the bytes of the byte slice or string.
As a special case, <code>append</code> also accepts a first argument assignable
to type <code>[]byte</code> with a second argument of string type followed by
<code>...</code>.
This form appends the bytes of the string.
</p>
<pre class="grammar">
append(s S, x ...E) S // core type of S is []E
append(s S, x ...E) S // E is the element type of S
</pre>
<p>
If <code>S</code> is a <a href="#Type_parameter_declarations">type parameter</a>,
all types in its type set must have the same underlying slice type <code>[]E</code>.
</p>
<p>
If the capacity of <code>s</code> is not large enough to fit the additional
values, <code>append</code> <a href="#Allocation">allocates</a> a new, sufficiently large underlying
@@ -7473,14 +7423,14 @@ b = append(b, "bar"...) // append string contents b is []byte{'b
The function <code>copy</code> copies slice elements from
a source <code>src</code> to a destination <code>dst</code> and returns the
number of elements copied.
The <a href="#Core_types">core types</a> of both arguments must be slices
with <a href="#Type_identity">identical</a> element type.
Both arguments must have <a href="#Type_identity">identical</a> element type
<code>E</code> and must be assignable to a slice of type <code>[]E</code>.
The number of elements copied is the minimum of
<code>len(src)</code> and <code>len(dst)</code>.
As a special case, if the destination's core type is <code>[]byte</code>,
<code>copy</code> also accepts a source argument with core type
<a href="#Core_types"><code>bytestring</code></a>.
This form copies the bytes from the byte slice or string into the byte slice.
As a special case, <code>copy</code> also accepts a destination argument
assignable to type <code>[]byte</code> with a source argument of a
<code>string</code> type.
This form copies the bytes from the string into the byte slice.
</p>
<pre class="grammar">
@@ -7488,6 +7438,11 @@ copy(dst, src []T) int
copy(dst []byte, src string) int
</pre>
<p>
If the type of one or both arguments is a <a href="#Type_parameter_declarations">type parameter</a>,
all types in their respective type sets must have the same underlying slice type <code>[]E</code>.
</p>
<p>
Examples:
</p>
@@ -7538,8 +7493,7 @@ If the map or slice is <code>nil</code>, <code>clear</code> is a no-op.
<h3 id="Close">Close</h3>
<p>
For an argument <code>ch</code> with a <a href="#Core_types">core type</a>
that is a <a href="#Channel_types">channel</a>, the built-in function <code>close</code>
For a channel <code>ch</code>, the built-in function <code>close(ch)</code>
records that no more values will be sent on the channel.
It is an error if <code>ch</code> is a receive-only channel.
Sending to or closing a closed channel causes a <a href="#Run_time_panics">run-time panic</a>.
@@ -7551,6 +7505,12 @@ The multi-valued <a href="#Receive_operator">receive operation</a>
returns a received value along with an indication of whether the channel is closed.
</p>
<p>
If the type of the argument to <code>close</code> is a
<a href="#Type_parameter_declarations">type parameter</a>,
all types in its type set must be channels with the same element type.
It is an error if any of those channels is a receive-only channel.
</p>
<h3 id="Complex_numbers">Manipulating complex numbers</h3>
@@ -7720,27 +7680,36 @@ var z complex128
<p>
The built-in function <code>make</code> takes a type <code>T</code>,
which must be a slice, map or channel type, or a type parameter,
optionally followed by a type-specific list of expressions.
The <a href="#Core_types">core type</a> of <code>T</code> must
be a slice, map or channel.
It returns a value of type <code>T</code> (not <code>*T</code>).
The memory is initialized as described in the section on
<a href="#The_zero_value">initial values</a>.
</p>
<pre class="grammar">
Call Core type Result
Call Type T Result
make(T, n) slice slice of type T with length n and capacity n
make(T, n, m) slice slice of type T with length n and capacity m
make(T, n) slice slice of type T with length n and capacity n
make(T, n, m) slice slice of type T with length n and capacity m
make(T) map map of type T
make(T, n) map map of type T with initial space for approximately n elements
make(T) map map of type T
make(T, n) map map of type T with initial space for approximately n elements
make(T) channel unbuffered channel of type T
make(T, n) channel buffered channel of type T, buffer size n
make(T) channel unbuffered channel of type T
make(T, n) channel buffered channel of type T, buffer size n
make(T, n) type parameter see below
make(T, n, m) type parameter see below
</pre>
<p>
If the first argument is a <a href="#Type_parameter_declarations">type parameter</a>,
all types in its type set must have the same underlying type, which must be a slice
or map type, or, if there are channel types, there must only be channel types, they
must all have the same element type, and the channel directions must not conflict.
</p>
<p>
Each of the size arguments <code>n</code> and <code>m</code> must be of <a href="#Numeric_types">integer type</a>,
have a <a href="#Interface_types">type set</a> containing only integer types,
@@ -7925,7 +7894,7 @@ causes a <a href="#Run_time_panics">run-time panic</a>.
<p>
The <code>protect</code> function in the example below invokes
the function argument <code>g</code> and protects callers from
run-time panics raised by <code>g</code>.
run-time panics caused by <code>g</code>.
</p>
<pre>
@@ -8483,17 +8452,14 @@ func String(ptr *byte, len IntegerType) string
func StringData(str string) *byte
</pre>
<!--
These conversions also apply to type parameters with suitable core types.
Determine if we can simply use core type instead of underlying type here,
of if the general conversion rules take care of this.
-->
<p>
A <code>Pointer</code> is a <a href="#Pointer_types">pointer type</a> but a <code>Pointer</code>
value may not be <a href="#Address_operators">dereferenced</a>.
Any pointer or value of <a href="#Core_types">core type</a> <code>uintptr</code> can be
<a href="#Conversions">converted</a> to a type of core type <code>Pointer</code> and vice versa.
Any pointer or value of <a href="#Underlying_types">underlying type</a> <code>uintptr</code> can be
<a href="#Conversions">converted</a> to a type of underlying type <code>Pointer</code> and vice versa.
If the respective types are <a href="#Type_parameter_declarations">type parameters</a>, all types in
their respective type sets must have the same underlying type, which must be <code>uintptr</code> and
<code>Pointer</code>, respectively.
The effect of converting between <code>Pointer</code> and <code>uintptr</code> is implementation-defined.
</p>
@@ -8847,9 +8813,9 @@ following conditions is true:
</li>
<li>
Exactly one type is an <a href="#Type_inference">unbound</a>
type parameter with a <a href="#Core_types">core type</a>,
and that core type unifies with the other type per the
unification rules for <code><sub>A</sub></code>
type parameter, and all the types in its type set unify with
the other type
per the unification rules for <code><sub>A</sub></code>
(loose unification at the top level and exact unification
for element types).
</li>

View File

@@ -109,7 +109,9 @@ Only the work module's `go.mod` is consulted for `godebug` directives.
Any directives in required dependency modules are ignored.
It is an error to list a `godebug` with an unrecognized setting.
(Toolchains older than Go 1.23 reject all `godebug` lines, since they do not
understand `godebug` at all.)
understand `godebug` at all.) When a workspace is in use, `godebug`
directives in `go.mod` files are ignored, and `go.work` will be consulted
for `godebug` directives instead.
The defaults from the `go` and `godebug` lines apply to all main
packages that are built. For more fine-grained control,
@@ -151,6 +153,47 @@ for example,
see the [runtime documentation](/pkg/runtime#hdr-Environment_Variables)
and the [go command documentation](/cmd/go#hdr-Build_and_test_caching).
### Go 1.25
Go 1.25 added a new `decoratemappings` setting that controls whether the Go
runtime annotates OS anonymous memory mappings with context about their
purpose. These annotations appear in /proc/self/maps and /proc/self/smaps as
"[anon: Go: ...]". This setting is only used on Linux. For Go 1.25, it defaults
to `decoratemappings=1`, enabling annotations. Using `decoratemappings=0`
reverts to the pre-Go 1.25 behavior. This setting is fixed at program startup
time, and can't be modified by changing the `GODEBUG` environment variable
after the program starts.
Go 1.25 added a new `embedfollowsymlinks` setting that controls whether the
Go command will follow symlinks to regular files embedding files.
The default value `embedfollowsymlinks=0` does not allow following
symlinks. `embedfollowsymlinks=1` will allow following symlinks.
Go 1.25 added a new `containermaxprocs` setting that controls whether the Go
runtime will consider cgroup CPU limits when setting the default GOMAXPROCS.
The default value `containermaxprocs=1` will use cgroup limits in addition to
the total logical CPU count and CPU affinity. `containermaxprocs=0` will
disable consideration of cgroup limits. This setting only affects Linux.
Go 1.25 added a new `updatemaxprocs` setting that controls whether the Go
runtime will periodically update GOMAXPROCS for new CPU affinity or cgroup
limits. The default value `updatemaxprocs=1` will enable periodic updates.
`updatemaxprocs=0` will disable periodic updates.
Go 1.25 disabled SHA-1 signature algorithms in TLS 1.2 according to RFC 9155.
The default can be reverted using the `tlssha1=1` setting.
Go 1.25 switched to SHA-256 to fill in missing SubjectKeyId in
crypto/x509.CreateCertificate. The setting `x509sha256skid=0` reverts to SHA-1.
Go 1.25 corrected the semantics of contention reports for runtime-internal locks,
and so removed the [`runtimecontentionstacks` setting](/pkg/runtime#hdr-Environment_Variables).
Go 1.25 (starting with Go 1.25 RC 2) disabled build information stamping when
multiple VCS are detected due to concerns around VCS injection attacks. This
behavior and setting was backported to Go 1.24.5 and Go 1.23.11. This behavior
can be renabled with the setting `allowmultiplevcs=1`.
### Go 1.24
Go 1.24 added a new `fips140` setting that controls whether the Go
@@ -217,6 +260,8 @@ field by default.
Go 1.24 enabled the post-quantum key exchange mechanism
X25519MLKEM768 by default. The default can be reverted using the
[`tlsmlkem` setting](/pkg/crypto/tls/#Config.CurvePreferences).
This can be useful when dealing with buggy TLS servers that do not handle large records correctly,
causing a timeout during the handshake (see [TLS post-quantum TL;DR fail](https://tldr.fail/)).
Go 1.24 also removed X25519Kyber768Draft00 and the Go 1.23 `tlskyber` setting.
Go 1.24 made [`ParsePKCS1PrivateKey`](/pkg/crypto/x509/#ParsePKCS1PrivateKey)
@@ -224,10 +269,6 @@ use and validate the CRT parameters in the encoded private key. This behavior
can be controlled with the `x509rsacrt` setting. Using `x509rsacrt=0` restores
the Go 1.23 behavior.
Go 1.24.5 disabled build information stamping when multiple VCS are detected due
to concerns around VCS injection attacks. This behavior can be renabled with the
setting `allowmultiplevcs=1`.
### Go 1.23
Go 1.23 changed the channels created by package time to be unbuffered
@@ -257,6 +298,8 @@ Previous versions default to `winreadlinkvolume=0`.
Go 1.23 enabled the experimental post-quantum key exchange mechanism
X25519Kyber768Draft00 by default. The default can be reverted using the
[`tlskyber` setting](/pkg/crypto/tls/#Config.CurvePreferences).
This can be useful when dealing with buggy TLS servers that do not handle large records correctly,
causing a timeout during the handshake (see [TLS post-quantum TL;DR fail](https://tldr.fail/)).
Go 1.23 changed the behavior of
[crypto/x509.ParseCertificate](/pkg/crypto/x509/#ParseCertificate) to reject
@@ -331,7 +374,7 @@ In particular, a common default Linux kernel configuration can result in
significant memory overheads, and Go 1.22 no longer works around this default.
To work around this issue without adjusting kernel settings, transparent huge
pages can be disabled for Go memory with the
[`disablethp` setting](/pkg/runtime#hdr-Environment_Variable).
[`disablethp` setting](/pkg/runtime#hdr-Environment_Variables).
This behavior was backported to Go 1.21.1, but the setting is only available
starting with Go 1.21.6.
This setting may be removed in a future release, and users impacted by this issue
@@ -343,7 +386,7 @@ Go 1.22 added contention on runtime-internal locks to the [`mutex`
profile](/pkg/runtime/pprof#Profile). Contention on these locks is always
reported at `runtime._LostContendedRuntimeLock`. Complete stack traces of
runtime locks can be enabled with the [`runtimecontentionstacks`
setting](/pkg/runtime#hdr-Environment_Variable). These stack traces have
setting](/pkg/runtime#hdr-Environment_Variables). These stack traces have
non-standard semantics, see setting documentation for details.
Go 1.22 added a new [`crypto/x509.Certificate`](/pkg/crypto/x509/#Certificate)
@@ -352,7 +395,7 @@ certificate policy OIDs with components larger than 31 bits. By default this
field is only used during parsing, when it is populated with policy OIDs, but
not used during marshaling. It can be used to marshal these larger OIDs, instead
of the existing PolicyIdentifiers field, by using the
[`x509usepolicies` setting.](/pkg/crypto/x509/#CreateCertificate).
[`x509usepolicies` setting](/pkg/crypto/x509/#CreateCertificate).
### Go 1.21

View File

@@ -1,3 +1,10 @@
### Minor changes to the library {#minor_library_changes}
#### go/types
The `Var.Kind` method returns an enumeration of type `VarKind` that
classifies the variable (package-level, local, receiver, parameter,
result, or struct field). See issue #70250.
Callers of `NewVar` or `NewParam` are encouraged to call `Var.SetKind`
to ensure that this attribute is set correctly in all cases.