Update to go1.25.0
This commit is contained in:
6864
doc/go1.17_spec.html
6864
doc/go1.17_spec.html
File diff suppressed because it is too large
Load Diff
@@ -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>
|
||||
|
||||
304
doc/go_spec.html
304
doc/go_spec.html
@@ -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<- E</code> or <code><-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<- int } // chan<- 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<- string } // channels have different element types
|
||||
interface{ <-chan int | chan<- 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><-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(<-ch)
|
||||
<-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 <- 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>
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user