From 21f05284c79c3e823169c62d189826f735006d43 Mon Sep 17 00:00:00 2001
From: Michael Matloob
- TODO: https://go.dev/cl/396215: add an Err field to LimitedReader
-
TODO: https://go.dev/cl/400236: NopCloser forward WriterTo implementations if the reader supports it
The Go memory model specifies the conditions under which
@@ -22,7 +19,7 @@ observe values produced by writes to the same variable in a different goroutine.
Programs that modify data being simultaneously accessed by multiple goroutines
@@ -44,90 +41,237 @@ you are being too clever.
Don't be clever.
-Within a single goroutine, reads and writes must behave
-as if they executed in the order specified by the program.
-That is, compilers and processors may reorder the reads and writes
-executed within a single goroutine only when the reordering
-does not change the behavior within that goroutine
-as defined by the language specification.
-Because of this reordering, the execution order observed
-by one goroutine may differ from the order perceived
-by another. For example, if one goroutine
-executes
-To specify the requirements of reads and writes, we define
-happens before, a partial order on the execution
-of memory operations in a Go program. If event e1 happens
-before event e2, then we say that e2 happens after e1.
-Also, if e1 does not happen before e2 and does not happen
-after e2, then we say that e1 and e2 happen concurrently.
-
-Within a single goroutine, the happens-before order is the
-order expressed by the program.
+A data race is defined as
+a write to a memory location happening concurrently with another read or write to that same location,
+unless all the accesses involved are atomic data accesses as provided by the
-A read r of a variable
+The following formal definition of Go's memory model closely follows
+the approach presented by Hans-J. Boehm and Sarita V. Adve in
+“Foundations of the C++ Concurrency Memory Model”,
+published in PLDI 2008.
+The definition of data-race-free programs and the guarantee of sequential consistency
+for race-free progams are equivalent to the ones in that work.
+
+The memory model describes the requirements on program executions,
+which are made up of goroutine executions,
+which in turn are made up of memory operations.
+
+A memory operation is modeled by four details:
+
+Some memory operations are read-like, including read, atomic read, mutex lock, and channel receive.
+Other memory operations are write-like, including write, atomic write, mutex unlock, channel send, and channel close.
+Some, such as atomic compare-and-swap, are both read-like and write-like.
+
+A goroutine execution is modeled as a set of memory operations executed by a single goroutine.
+
+Requirement 1:
+The memory operations in each goroutine must correspond to a correct sequential execution of that goroutine,
+given the values read from and written to memory.
+That execution must be consistent with the sequenced before relation,
+defined as the partial order requirements set out by the Go language specification
+for Go's control flow constructs as well as the order of evaluation for expressions.
+
+A Go program execution is modeled as a set of goroutine executions,
+together with a mapping W that specifies the write-like operation that each read-like operation reads from.
+(Multiple executions of the same program can have different program executions.)
+
+Requirement 2:
+For a given program execution, the mapping W, when limited to synchronizing operations,
+must be explainable by some implicit total order of the synchronizing operations
+that is consistent with sequencing and the values read and written by those operations.
+
+The synchronized before relation is a partial order on synchronizing memory operations,
+derived from W.
+If a synchronizing read-like memory operation r
+observes a synchronizing write-like memory operation w
+(that is, if W(r) = w),
+then w is synchronized before r.
+Informally, the synchronized before relation is a subset of the implied total order
+mentioned in the previous paragraph,
+limited to the information that W directly observes.
+
+The happens before relation is defined as the transitive closure of the
+union of the sequenced before and synchronized before relations.
+
+Requirement 3:
+For an ordinary (non-synchronizing) data read r on a memory location x,
+W(r) must be a write w that is visible to r,
+where visible means that both of the following hold:
+
-To guarantee that a read r of a variable
-This pair of conditions is stronger than the first pair;
-it requires that there are no other writes happening
-concurrently with w or r.
+A read-write data race on memory location x
+consists of a read-like memory operation r on x
+and a write-like memory operation w on x,
+at least one of which is non-synchronizing,
+which are unordered by happens before
+(that is, neither r happens before w
+nor w happens before r).
-Within a single goroutine,
-there is no concurrency, so the two definitions are equivalent:
-a read r observes the value written by the most recent write w to
-The initialization of variable
-Reads and writes of values larger than a single machine word
-behave as multiple machine-word-sized operations in an
-unspecified order.
+More generally, it can be shown that any Go program that is data-race-free,
+meaning it has no program executions with read-write or write-write data races,
+can only have outcomes explained by some sequentially consistent interleaving
+of the goroutine executions.
+(The proof is the same as Section 7 of Boehm and Adve's paper cited above.)
+This property is called DRF-SC.
+The intent of the formal definition is to match
+the DRF-SC guarantee provided to race-free programs
+by other languages, including C, C++, Java, JavaScript, Rust, and Swift.
+
+Certain Go language operations such as goroutine creation and memory allocation
+act as synchronization opeartions.
+The effect of these operations on the synchronized-before partial order
+is documented in the “Synchronization” section below.
+Individual packages are responsible for providing similar documentation
+for their own operations.
+
+The preceding section gave a formal definition of data-race-free program execution.
+This section informally describes the semantics that implementations must provide
+for programs that do contain races.
+
+First, any implementation can, upon detecting a data race,
+report the race and halt execution of the program.
+Implementations using ThreadSanitizer
+(accessed with “
+Otherwise, a read r of a memory location x
+that is not larger than a machine word must observe
+some write w such that r does not happen before w
+and there is no write w' such that w happens before w'
+and w' happens before r.
+That is, each read must observe a value written by a preceding or concurrent write.
+
+Additionally, observation of acausal and “out of thin air” writes is disallowed.
+
+Reads of memory locations larger than a single machine word
+are encouraged but not required to meet the same semantics
+as word-sized memory locations,
+observing a single allowed write w.
+For performance reasons,
+implementations may instead treat larger operations
+as a set of individual machine-word-sized operations
+in an unspecified order.
+This means that races on multiword data structures
+can lead to inconsistent values not corresponding to a single write.
+When the values depend on the consistency
+of internal (pointer, length) or (pointer, type) pairs,
+as can be the case for interface values, maps,
+slices, and strings in most Go implementations,
+such races can in turn lead to arbitrary memory corruption.
+
+Examples of incorrect synchronization are given in the
+“Incorrect synchronization” section below.
+
+Examples of the limitations on implementations are given in the
+“Incorrect compilation” section below.
+
Program initialization runs in a single goroutine,
@@ -141,15 +285,15 @@ If a package
-The start of the function
The
@@ -174,11 +318,12 @@ calling
-The exit of a goroutine is not guaranteed to happen before
-any event in the program. For example, in this program:
+The exit of a goroutine is not guaranteed to be synchronized before
+any event in the program.
+For example, in this program:
Introduction
+Introduction
Advice
+Advice
Happens Before
+Informal Overview
a = 1; b = 2;, another might observe
-the updated value of b before the updated value of a.
+Go approaches its memory model in much the same way as the rest of the language,
+aiming to keep the semantics simple, understandable, and useful.
+This section gives a general overview of the approach and should suffice for most programmers.
+The memory model is specified more formally in the next section.
sync/atomic package.
+As noted already, programmers are strongly encouraged to use appropriate synchronization
+to avoid data races.
+In the absence of data races, Go programs behave as if all the goroutines
+were multiplexed onto a single processor.
+This property is sometimes referred to as DRF-SC: data-race-free programs
+execute in a sequentially consistent manner.
v is allowed to observe a write w to v
-if both of the following hold:
+While programmers should write Go programs without data races,
+there are limitations to what a Go implementation can do in response to a data race.
+An implementation may always react to a data race by reporting the race and terminating the program.
+Otherwise, each read of a single-word-sized or sub-word-sized memory location
+must observe a value actually written to that location (perhaps by a concurrent executing goroutine)
+and not yet overwritten.
+These implementation constraints make Go more like Java or JavaScript,
+in that most races have a limited number of outcomes,
+and less like C and C++, where the meaning of any program with a race
+is entirely undefined, and the compiler may do anything at all.
+Go's approach aims to make errant programs more reliable and easier to debug,
+while still insisting that races are errors and that tools can diagnose and report them.
Memory Model
+
+
+
+
-
v that happens
- after w but before r.v observes a
-particular write w to v, ensure that w is the only
-write r is allowed to observe.
-That is, r is guaranteed to observe w if both of the following hold:
-
-
-
-v
-either happens before w or after r.v.
-When multiple goroutines access a shared variable v,
-they must use synchronization events to establish
-happens-before conditions that ensure reads observe the
-desired writes.
+A write-write data race on memory location x
+consists of two write-like memory operations w and w' on x,
+at least one of which is non-synchronizing,
+which are unordered by happens before.
v with the zero value
-for v's type behaves as a write in the memory model.
+Note that if there are no read-write or write-write data races on memory location x,
+then any read r on x has only one possible W(r):
+the single w that immediately precedes it in the happens before order.
Synchronization
+Initialization
+Implementation Restrictions for Programs Containing Data Races
+
+go build -race”)
+do exactly this.
+Synchronization
+
+Initialization
p imports package q, the completion of
main.main happens after
-all init functions have finished.
+The completion of all init functions is synchronized before
+the start of the function main.main.
Goroutine creation
+Goroutine creation
go statement that starts a new goroutine
-happens before the goroutine's execution begins.
+is synchronized before the start of the goroutine's execution.
hello will print "hello, world"
at some point in the future (perhaps after hello has returned).
Goroutine destruction
+Goroutine destruction
@@ -203,7 +348,7 @@ use a synchronization mechanism such as a lock or channel
communication to establish a relative ordering.
Channel communication is the main method of synchronization @@ -213,8 +358,8 @@ usually in a different goroutine.
-A send on a channel happens before the corresponding -receive from that channel completes. +A send on a channel is synchronized before the completion of the +corresponding receive from that channel.
@@ -239,13 +384,13 @@ func main() {
is guaranteed to print "hello, world". The write to a
-happens before the send on c, which happens before
-the corresponding receive on c completes, which happens before
+is sequenced before the send on c, which is synchronized before
+the corresponding receive on c completes, which is sequenced before
the print.
-The closing of a channel happens before a receive that returns a zero value +The closing of a channel is synchronized before a receive that returns a zero value because the channel is closed.
@@ -256,8 +401,8 @@ yields a program with the same guaranteed behavior.-A receive from an unbuffered channel happens before -the send on that channel completes. +A receive from an unbuffered channel is synchronized before the completion of +the corresponding send on that channel.
@@ -283,8 +428,8 @@ func main() {
is also guaranteed to print "hello, world". The write to a
-happens before the receive on c, which happens before
-the corresponding send on c completes, which happens
+is sequenced before the receive on c, which is synchronized before
+the corresponding send on c completes, which is sequenced
before the print.
-The kth receive on a channel with capacity C happens before the k+Cth send from that channel completes. +The kth receive on a channel with capacity C is synchronized before the completion of the k+Cth send from that channel completes.
@@ -330,7 +475,7 @@ func main() { } -
The sync package implements two lock data types,
@@ -339,7 +484,7 @@ The sync package implements two lock data types,
For any sync.Mutex or sync.RWMutex variable l and n < m,
-call n of l.Unlock() happens before call m of l.Lock() returns.
+call n of l.Unlock() is synchronized before call m of l.Lock() returns.
@@ -365,19 +510,29 @@ func main() {
is guaranteed to print "hello, world".
-The first call to l.Unlock() (in f) happens
+The first call to l.Unlock() (in f) is synchronized
before the second call to l.Lock() (in main) returns,
-which happens before the print.
+which is sequenced before the print.
For any call to l.RLock on a sync.RWMutex variable l,
-there is an n such that the l.RLock happens (returns) after call n to
-l.Unlock and the matching l.RUnlock happens
-before call n+1 to l.Lock.
+there is an n such that the nth call to l.Unlock
+is synchronized before the return from l.RLock,
+and the matching call to l.RUnlock is synchronized before the return from call n+1 to l.Lock.
+A successful call to l.TryLock (or l.TryRLock)
+is equivalent to a call to l.Lock (or l.RLock).
+An unsuccessful call has no synchronizing effect at all.
+As far as the memory model is concerned,
+l.TryLock (or l.TryRLock)
+may be considered to be able to return false
+even when the mutex l is unlocked.
+
The sync package provides a safe mechanism for
@@ -389,7 +544,8 @@ until f() has returned.
-A single call of f() from once.Do(f) happens (returns) before any call of once.Do(f) returns.
+The completion of a single call of f() from once.Do(f)
+is synchronized before the return of any call of once.Do(f).
@@ -424,13 +580,60 @@ The result will be that "hello, world" will be printed
twice.
-Note that a read r may observe the value written by a write w
-that happens concurrently with r.
-Even if this occurs, it does not imply that reads happening after r
-will observe writes that happened before w.
+The APIs in the sync/atomic
+package are collectively “atomic operations”
+that can be used to synchronize the execution of different goroutines.
+If the effect of an atomic operation A is observed by atomic operation B,
+then A is synchronized before B.
+All the atomic operations executed in a program behave as though executed
+in some sequentially consistent order.
+
+The preceding definition has the same semantics as C++’s sequentially consistent atomics
+and Java’s volatile variables.
+
+The runtime package provides
+a SetFinalizer function that adds a finalizer to be called when
+a particular object is no longer reachable by the program.
+A call to SetFinalizer(x, f) is synchronized before the finalization call f(x).
+
+The sync package provides additional synchronization abstractions,
+including condition variables,
+lock-free maps,
+allocation pools,
+and
+wait groups.
+The documentation for each of these specifies the guarantees it
+makes concerning synchronization.
+
+Other packages that provide synchronization abstractions +should document the guarantees they make too. +
+ + ++Programs with races are incorrect and +can exhibit non-sequentially consistent executions. +In particular, note that a read r may observe the value written by any write w +that executes concurrently with r. +Even if this occurs, it does not imply that reads happening after r +will observe writes that happened before w.
@@ -566,3 +769,197 @@ value for g.msg.
In all these examples, the solution is the same:
use explicit synchronization.
+The Go memory model restricts compiler optimizations as much as it does Go programs. +Some compiler optimizations that would be valid in single-threaded programs are not valid in all Go programs. +In particular, a compiler must not introduce writes that do not exist in the original program, +it must not allow a single read to observe multiple values, +and it must not allow a single write to write multiple values. +
+ ++All the following examples assume that `*p` and `*q` refer to +memory locations accessible to multiple goroutines. +
+ ++Not introducing data races into race-free programs means not moving +writes out of conditional statements in which they appear. +For example, a compiler must not invert the conditional in this program: +
+ +
+*p = 1
+if cond {
+ *p = 2
+}
+
+
++That is, the compiler must not rewrite the program into this one: +
+ +
+*p = 2
+if !cond {
+ *p = 1
+}
+
+
+
+If cond is false and another goroutine is reading *p,
+then in the original program, the other goroutine can only observe any prior value of *p and 1.
+In the rewritten program, the other goroutine can observe 2, which was previously impossible.
+
+Not introducing data races also means not assuming that loops terminate.
+For example, a compiler must in general not move the accesses to *p or *q
+ahead of the loop in this program:
+
+n := 0
+for e := list; e != nil; e = e.next {
+ n++
+}
+i := *p
+*q = 1
+
+
+
+If list pointed to a cyclic list,
+then the original program would never access *p or *q,
+but the rewritten program would.
+(Moving `*p` ahead would be safe if the compiler can prove `*p` will not panic;
+moving `*q` ahead would also require the compiler proving that no other
+goroutine can access `*q`.)
+
+Not introducing data races also means not assuming that called functions
+always return or are free of synchronization operations.
+For example, a compiler must not move the accesses to *p or *q
+ahead of the function call in this program
+(at least not without direct knowledge of the precise behavior of f):
+
+f() +i := *p +*q = 1 ++ +
+If the call never returned, then once again the original program
+would never access *p or *q, but the rewritten program would.
+And if the call contained synchronizing operations, then the original program
+could establish happens before edges preceding the accesses
+to *p and *q, but the rewritten program would not.
+
+Not allowing a single read to observe multiple values means
+not reloading local variables from shared memory.
+For example, a compiler must not discard i and reload it
+a second time from *p in this program:
+
+i := *p
+if i < 0 || i >= len(funcs) {
+ panic("invalid function index")
+}
+... complex code ...
+// compiler must NOT reload i = *p here
+funcs[i]()
+
+
+
+If the complex code needs many registers, a compiler for single-threaded programs
+could discard i without saving a copy and then reload
+i = *p just before
+funcs[i]().
+A Go compiler must not, because the value of *p may have changed.
+(Instead, the compiler could spill i to the stack.)
+
+Not allowing a single write to write multiple values also means not using
+the memory where a local variable will be written as temporary storage before the write.
+For example, a compiler must not use *p as temporary storage in this program:
+
+*p = i + *p/2 ++ +
+That is, it must not rewrite the program into this one: +
+ ++*p /= 2 +*p += i ++ +
+If i and *p start equal to 2,
+the original code does *p = 3,
+so a racing thread can read only 2 or 3 from *p.
+The rewritten code does *p = 1 and then *p = 3,
+allowing a racing thread to read 1 as well.
+
+Note that all these optimizations are permitted in C/C++ compilers: +a Go compiler sharing a back end with a C/C++ compiler must take care +to disable optimizations that are invalid for Go. +
+ ++Note that the prohibition on introducing data races +does not apply if the compiler can prove that the races +do not affect correct execution on the target platform. +For example, on essentially all CPUs, it is valid to rewrite +
+ +
+n := 0
+for i := 0; i < m; i++ {
+ n += *shared
+}
+
+
+into:
+
+
+n := 0
+local := *shared
+for i := 0; i < m; i++ {
+ n += local
+}
+
+
+
+provided it can be proved that *shared will not fault on access,
+because the potential added read will not affect any existing concurrent reads or writes.
+On the other hand, the rewrite would not be valid in a source-to-source translator.
+
+Go programmers writing data-race-free programs can rely on +sequentially consistent execution of those programs, +just as in essentially all other modern programming languages. +
+ ++When it comes to programs with races, +both programmers and compilers should remember the advice: +don't be clever. +
From 0293c51bc5d8ca0728913c4b7f9f92339f8fd9a6 Mon Sep 17 00:00:00 2001 From: Bryan Boreham+ TODO: https://go.dev/cl/395535: add Var.Origin and Func.Origin +
++ TODO: https://go.dev/cl/404885: a finite number of types are reachable via Named.Underlying, Named.Method +
+
From 07eca49055f7ef0d73be2ca28dcc5d489db129b9 Mon Sep 17 00:00:00 2001
From: Robert Griesemer Doubled single quotes like “ and ” turn into Unicode double quotes,
but single quotes ` and ' do not.
+Misplaced markdown fences ``` do not either.
From ea5d7cbc2644643331bd675b1ebdf0aaac7419f1 Mon Sep 17 00:00:00 2001
From: Russ Cox
- TODO: https://go.dev/cl/400654: permit use of Resolver.PreferGo, netgo on Windows and Plan 9
+ Resolver.PreferGo
+ is now implemented on Windows and Plan 9. It previously only worked on Unix
+ platforms. Combined with
+ Dialer.Resolver and
+ Resolver.Dial, it's now
+ possible to write portable programs and be in control of all DNS name lookups
+ when dialing.
+
+ The net package now has initial support for the netgo
+ build tag on Windows. When used, the package uses the Go DNS client (as used
+ by Resolver.PreferGo) instead of asking Windows for
+ DNS results. The upstream DNS server it discovers from Windows
+ may not yet be correct with complex system network configurations, however.
TODO: https://go.dev/cl/402374: enable regabi on riscv64 by default
-- TODO: https://go.dev/cl/391014: The Go compiler now requires the -p=importpath flag, which is already supplied by the go command and by Bazel. Any other build systems that invoke the Go compiler directly will need to make sure they pass this flag as well in order to use Go 1.19.: cmd/compile: require -p flag +
+ The Go compiler now requires the -p=importpath flag to
+ build a linkable object file. This is already supplied by
+ the go command and by Bazel. Any other build systems
+ that invoke the Go compiler directly will need to make sure they
+ pass this flag as well.
TODO: complete this section, or delete if not needed
From 4c08260c51c6ebe405a78a30f970014af763ca38 Mon Sep 17 00:00:00 2001
From: Russ Cox
- TODO: soft memory limit
+
+ The runtime now includes support for a soft memory limit. This memory limit
+ includes all memory mapped and managed by the runtime, and excludes external
+ memory sources such as binary size, memory managed in other languages, and
+ memory held by the operating system on behalf of the Go program. This limit
+ may be managed via the
+ In order to limit the effects of GC thrashing when the program's live heap
+ size approaches the soft memory limit, the Go runtime also attempts to limit
+ total GC CPU utilization to 50%, excluding idle time, choosing to use more
+ memory over preventing application progress. In practice, we expect this limit
+ to only play a role in exceptional cases, and the new runtime/metrics metric
+
- TODO: idle mark workers
+ The runtime now schedules many fewer GC worker goroutines on idle operating
+ system threads when the application is idle enough to force a periodic GC
+ cycle.
@@ -494,7 +519,7 @@ Do not send CLs removing the interior tags from such phrases.
When used together with the
CPU profiler, the
- execution trace includes CPU profile samples.
+ execution trace includes CPU profile samples as instantaneous events.
Runtime
-GOMEMLIMIT environment variable or the
+ SetMemoryLimit function in the runtime/debug package. The limit
+ works in conjunction with GOGC and SetGCPercent,
+ and will be respected even if GOGC=off, allowing Go programs to
+ always make maximal use of their memory limit, improving resource efficiency
+ in some cases. Please note that small memory limits, on the order of tens of
+ megabytes or less, are less likely to be adhered to due to external latency
+ factors, such as OS scheduling. See https://go.dev/issue/52433 for more
+ details. Larger memory limits, on the order of hundreds of megabytes or more,
+ are stable and production-ready.
+/gc/limiter/last-enabled:gc-cycle reports when this last
+ occurred.
TODO: complete this section
+ ++ TODO: https://go.dev/issue/52038: adjust scope of type parameters declared by method receivers +
+TODO: complete this section, or delete if not needed
+TODO: complete this section, or delete if not needed
+: + TODO: https://go.dev/issue/47528 warn when errors.As target has type *error +
+ ++ TODO: complete this section. +
+TODO: complete this section. @@ -66,7 +82,7 @@ Do not send CLs removing the interior tags from such phrases.
unix build constraint+
The build constraint unix is now recognized
in //go:build lines. The constraint is satisfied
if the target operating system, also known as GOOS, is
@@ -146,6 +162,10 @@ Do not send CLs removing the interior tags from such phrases.
functionality.
+ TODO: https://go.dev/issue/44853: enable address sanitizer in Go +
+
@@ -156,7 +176,7 @@ Do not send CLs removing the interior tags from such phrases.
on the order of 20% faster.
(GOARCH=amd64 and GOARCH=arm64 only)
+
TODO: https://go.dev/cl/402374: enable regabi on riscv64 by default
@@ -165,7 +185,7 @@ Do not send CLs removing the interior tags from such phrases.
the go command and by Bazel. Any other build systems
that invoke the Go compiler directly will need to make sure they
pass this flag as well.
-
TODO: complete this section, or delete if not needed
@@ -176,6 +196,14 @@ Do not send CLs removing the interior tags from such phrases.+ TODO: https://go.dev/issue/51940: all: move dev.boringcrypto into main branch behind GOEXPERIMENT +
+ ++ TODO: complete this section +
+
The sync/atomic package defines new atomic types
@@ -197,13 +225,26 @@ Do not send CLs removing the interior tags from such phrases.
atomics on these systems.
- TODO: https://go.dev/issue/51940: all: move dev.boringcrypto into main branch behind GOEXPERIMENT +
+ TODO: https://go.dev/cl/384265: go/doc: use go/doc/comment; modified api/next/51082.txt + TODO: https://go.dev/cl/397276: go/doc/comment: add data structures; modified api/next/51082.txt + TODO: https://go.dev/cl/397278: go/doc/comment: add paragraph parsing and test framework; modified api/next/51082.txt + TODO: https://go.dev/cl/397279: go/doc/comment: add Printer and basic comment printing; modified api/next/51082.txt + TODO: https://go.dev/cl/397281: go/doc/comment: parse and print doc links; modified api/next/51082.txt + TODO: https://go.dev/cl/397284: go/doc/comment: parse and print headings; modified api/next/51082.txt
-- TODO: complete this section +
+ TODO: https://go.dev/issue/43724: return error when PATH lookup would use current directory
++ TODO: https://go.dev/issue/43947: on Windows use NeedCurrentDirectoryForExePathW for LookPath behavior +
+@@ -241,7 +282,7 @@ Do not send CLs removing the interior tags from such phrases.
+
The tls10default GODEBUG option has been
removed. It is still possible to enable TLS 1.0 client-side by setting
Config.MinVersion.
@@ -254,28 +295,78 @@ Do not send CLs removing the interior tags from such phrases.
TODO: https://go.dev/cl/285872: disable signing with MD5WithRSA
+ ++ TODO: https://go.dev/issue/46057: add CertPool.Equal +
+ ++ TODO: https://go.dev/issue/50674: add ParseRevocationList, deprecate ParseCRL & ParseDERCRL +
+ ++ TODO: https://go.dev/cl/390834: crypto/x509: add new CRL parser, deprecate old one; modified api/next/50674.txt +
+ ++ TODO: https://go.dev/cl/400175: crypto/x509: add CertPool.Clone; modified api/next/35044.txt + TODO: https://go.dev/issue/35044: add CertPool.Clone +
+ TODO: https://go.dev/cl/396735: debug: define ELF relocation for loong64; modified api/next/46229.txt +
++ TODO: https://go.dev/issue/51868: add APIs to support reading COMDAT info for sections +
+ ++ TODO: https://go.dev/cl/394534: debug/pe: add APIs for reading section def aux info; modified api/next/51868.txt +
++
TODO: https://go.dev/cl/386017: add AppendByteOrder
++ TODO: https://go.dev/issue/51644: add AppendUvarint and AppendVarint +
++
TODO: https://go.dev/cl/405675: add Reader.InputOffset method
+ TODO: https://go.dev/issue/45628: add Decoder.InputPos + TODO: https://go.dev/cl/311270: encoding/xml: expose decoder line and column; modified api/next/45628.txt +
++
TODO: https://go.dev/cl/313329: add TextVar function
+
TODO: https://go.dev/cl/406177: add Append, Appendln, Appendf
+
TODO: https://go.dev/cl/395535: add Var.Origin and Func.Origin
@@ -308,6 +399,25 @@ Do not send CLs removing the interior tags from such phrases.
+ TODO: https://go.dev/cl/392494: hash/maphash: add Bytes and String; modified api/next/42710.txt + TODO: https://go.dev/issue/42710: add Bytes and String +
++ TODO: https://go.dev/issue/46121: make FuncMap an alias for text/template.FuncMap + TODO: https://go.dev/cl/389156: html/template: make FuncMap a type alias of text/template.FuncMap; modified api/except.txt, api/next/46121.txt +
+@@ -322,9 +432,13 @@ Do not send CLs removing the interior tags from such phrases.
+
TODO: https://go.dev/cl/400236: NopCloser forward WriterTo implementations if the reader supports it
+ ++ TODO: https://go.dev/issue/50842: implement WriterTo on result of MultiReader +
+
When a net package function or method returns an "I/O timeout"
error, the error will now satisfy errors.Is(err,
context.DeadlineExceeded). When a net package function
@@ -369,9 +483,7 @@ Do not send CLs removing the interior tags from such phrases.
package function or method to return an error, while preserving
backward compatibility for error messages.
+
Resolver.PreferGo
is now implemented on Windows and Plan 9. It previously only worked on Unix
platforms. Combined with
@@ -395,14 +507,22 @@ Do not send CLs removing the interior tags from such phrases.
TODO: https://go.dev/cl/269997: allow sending 1xx responses
++ TODO: https://go.dev/cl/361397: net/http: add MaxBytesError; modified api/next/30715.txt + TODO: https://go.dev/issue/30715: add MaxBytesError +
+
TODO: https://go.dev/cl/374654: add JoinPath, URL.JoinPath
++ TODO: https://go.dev/issue/46059: add OmitHost bool to URL +
++
An exec.Cmd with a non-empty Dir and a
nil Env now implicitly sets the PWD environment
variable for the subprocess to match Dir.
@@ -432,7 +552,7 @@ Do not send CLs removing the interior tags from such phrases.
+
The method Value.Bytes now accepts addressable arrays in addition to slices.
@@ -441,6 +561,25 @@ Do not send CLs removing the interior tags from such phrases.
+ TODO: https://go.dev/issue/51684: add ErrNestingDepth error + TODO: https://go.dev/cl/401076: regexp: change ErrInvalidDepth message to match proposal; modified api/next/51684.txt, api/next/regexpdepth.txt +
++ TODO: https://go.dev/cl/384617: regexp/syntax: add and use ErrInvalidDepth; modified api/next/regexpdepth.txt + TODO: https://go.dev/cl/401854: regexp/syntax: rename ErrInvalidDepth to ErrNestingDepth; modified api/next/51684.txt +
+@@ -452,6 +591,14 @@ Do not send CLs removing the interior tags from such phrases.
+ TODO: https://go.dev/cl/397018: runtime/debug: export SetMemoryLimit; modified api/next/48409.txt +
+@@ -531,6 +678,11 @@ Do not send CLs removing the interior tags from such phrases. pattern-defeating quicksort, which is faster for several common scenarios.
++ TODO: https://go.dev/issue/50340: add Find + TODO: https://go.dev/cl/396514: sort: add Find function; modified api/next/50340.txt +
++
TODO: https://go.dev/cl/393515: add Duration.Abs + TODO: https://go.dev/issue/51414: add Duration.Abs +
++ TODO: https://go.dev/issue/50062: add Time.ZoneBounds + TODO: https://go.dev/cl/405374: time: add Time.ZoneBounds; modified api/next/50062.txt
- TODO: https://go.dev/issue/51940: all: move dev.boringcrypto into main branch behind GOEXPERIMENT -
-TODO: complete this section
From 38607c553878da21b5042e63997ecb3b7201e684 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Motiejus=20Jak=C5=A1tys?=- TODO: https://go.dev/cl/370894: batch and buffer calls to getrandom/getentropy +
+ Read no longer buffers
+ random data obtained from the operating system between calls.
- TODO: https://go.dev/cl/375215: use fast key erasure RNG on plan9 instead of ANSI X9.31 -
- -
- TODO: https://go.dev/cl/390038: remove all buffering
+ On Plan 9, Read has been reimplemented, replacing the ANSI
+ X9.31 algorithm with fast key erasure.
The tls10default GODEBUG option has been
removed. It is still possible to enable TLS 1.0 client-side by setting
- Config.MinVersion.
+ Config.MinVersion.
+
+ The TLS server and client now reject duplicate extensions in TLS + handshakes, as required by RFC 5246, Section 7.4.1.4 and RFC 8446, Section + 4.2.
- TODO: https://go.dev/cl/285872: disable signing with MD5WithRSA
+ CreateCertificate
+ no longer supports creating certificates with SignatureAlgorithm
+ set to MD5WithRSA.
+
+ CreateCertificate no longer accepts negative serial numbers.
+
+ ParseCertificate
+ and ParseCertificateRequest
+ now reject certificates and CSRs which contain duplicate extensions.
+
+ The new CertPool.Clone
+ and CertPool.Equal
+ methods allow cloning a CertPool and checking the equality of two
+ CertPools respectively.
+
+ The new function ParseRevocationList
+ provides a faster, safer to use CRL parser which returns a
+ RevocationList.
+ To support this addition, RevocationList adds new fields
+ RawIssuer, Signature,
+ AuthorityKeyId, and Extensions.
+
+ The new method RevocationList.CheckSignatureFrom
+ checks that the signature on a CRL is a valid signature from a
+ Certificate.
+
+ With the new CRL functionality, the existing functions
+ ParseCRL and
+ ParseDERCRL are deprecated.
+ Additionally the method Certificate.CheckCRLSignature
+ is deprecated.
+
+ When building paths, Certificate.Verify
+ now considers certificates to be equal when the subjects, public keys, and SANs
+ are all equal. Before, it required byte-for-byte equality.
@@ -311,6 +359,17 @@ Do not send CLs removing the interior tags from such phrases.
+ The types CertificateList and
+ TBSCertificateList
+ have been deprecated. The new crypto/x509 CRL functionality
+ should be used instead.
+
From 429a4041eb2657fad8870cad5662202f3bd0eeb6 Mon Sep 17 00:00:00 2001
From: Robert Findley
- TODO: https://go.dev/cl/395535: add Var.Origin and Func.Origin
+ The new methods
- TODO: https://go.dev/cl/404885: a finite number of types are reachable via Named.Underlying, Named.Method
+
+ It is no longer possible to produce an infinite number of distinct-but-identical
+
The race detector has been upgraded to use thread sanitizer
- version v3.
-
From 835a94613703bb856ea4d16f05c116399c4b2fc9 Mon Sep 17 00:00:00 2001
From: Austin Clements Func.Origin
+ and Var.Origin return the
+ corresponding Object of the
+ generic type for synthetic Func
+ and Var objects created during type
+ instantiation.
Named type instantiations via
+ recursive calls to
+ Named.Underlying or
+ Named.Method.
-
+ version v3. Compared to v2, it is now typically 1.5x to 2x
+ faster, uses half as much memory, and it supports an unlimited
+ number of goroutines.
- The race detector is now supported on S390.
+ The race detector is now supported on GOARCH=s390x.
- When used together with the - CPU profiler, the - execution trace includes CPU profile samples as instantaneous events. + When tracing and the + CPU profiler are + enabled simultaneously, the execution trace includes CPU profile + samples as instantaneous events.
go command and by Bazel. Any other build systems
that invoke the Go compiler directly will need to make sure they
pass this flag as well.
-
-- TODO: complete this section, or delete if not needed
+
TODO: complete this section, or delete if not needed
From 81033fbd8e414447049e356af382fa6ecca072ea Mon Sep 17 00:00:00 2001
From: Austin Clements
The race detector has been upgraded to use thread sanitizer
- version v3. Compared to v2, it is now typically 1.5x to 2x
- faster, uses half as much memory, and it supports an unlimited
- number of goroutines.
+ version v3 on all supported platforms
+ except
The race detector is now supported on
+ Race detector support for windows/amd64
+ and openbsd/amd64, which remain on v2.
+ Compared to v2, it is now typically 1.5x to 2x faster, uses half
+ as much memory, and it supports an unlimited number of
+ goroutines.
GOARCH=s390x.
openbsd/amd64 has been
+ removed from thread sanitizer upstream, so it is unlikely to
+ ever be updated from v2.
+
TODO: complete this section, or delete if not needed
+
+ Go 1.19 supports the Loongson 64-bit architecture LoongArch on Linux (GOOS=linux, GOARCH=loong64).
+
From f3e051a184ddd060f1e17200b0081648411fa073 Mon Sep 17 00:00:00 2001
From: Michael Pratt
The runtime now includes support for a soft memory limit. This memory limit
- includes all memory mapped and managed by the runtime, and excludes external
- memory sources such as binary size, memory managed in other languages, and
- memory held by the operating system on behalf of the Go program. This limit
- may be managed via the
@@ -123,7 +130,8 @@ Do not send CLs removing the interior tags from such phrases.
size approaches the soft memory limit, the Go runtime also attempts to limit
total GC CPU utilization to 50%, excluding idle time, choosing to use more
memory over preventing application progress. In practice, we expect this limit
- to only play a role in exceptional cases, and the new runtime/metrics metric
+ to only play a role in exceptional cases, and the new
+ runtime metric
- The new
- The new
- The new
- TODO: https://go.dev/cl/269997: allow sending 1xx responses
+
- TODO: https://go.dev/cl/361397: net/http: add MaxBytesError; modified api/next/30715.txt
- TODO: https://go.dev/issue/30715: add MaxBytesError
+
+
+ The
+ The HTTP client will handle a 3xx response without a
+
- TODO: https://go.dev/cl/374654: add JoinPath, URL.JoinPath
+
+ The new
+
- TODO: https://go.dev/issue/46059: add OmitHost bool to URL
+ The
+ The new GOMEMLIMIT environment variable or the
- SetMemoryLimit function in the runtime/debug package. The limit
- works in conjunction with GOGC and SetGCPercent,
+ includes the Go heap and all other memory managed by the runtime, and
+ excludes external memory sources such as mappings of the binary itself,
+ memory managed in other languages, and memory held by the operating system on
+ behalf of the Go program. This limit may be managed via
+ runtime/debug.SetMemoryLimit
+ or the equivalent
+ GOMEMLIMIT
+ environment variable. The limit works in conjunction with
+ runtime/debug.SetGCPercent
+ / GOGC,
and will be respected even if GOGC=off, allowing Go programs to
always make maximal use of their memory limit, improving resource efficiency
- in some cases. Please note that small memory limits, on the order of tens of
- megabytes or less, are less likely to be adhered to due to external latency
- factors, such as OS scheduling. See https://go.dev/issue/52433 for more
- details. Larger memory limits, on the order of hundreds of megabytes or more,
- are stable and production-ready.
+ in some cases. See the GC guide for
+ a detailed guide explaining the soft memory limit in more detail, as well as
+ a variety of common use-cases and scenarios. Please note that small memory
+ limits, on the order of tens of megabytes or less, are less likely to be
+ respected due to external latency factors, such as OS scheduling. See
+ issue 52433 for more details. Larger
+ memory limits, on the order of hundreds of megabytes or more, are stable and
+ production-ready.
/gc/limiter/last-enabled:gc-cycle reports when this last
occurred.
From 346698eea71139280e3b3380554371b5d332ce02 Mon Sep 17 00:00:00 2001
From: Damien Neil /sched/gomaxprocs:threads metric reports the current
- runtime.GOMAXPROCS value.
+ The new /sched/gomaxprocs:threads
+ metric reports
+ the current
+ runtime.GOMAXPROCS
+ value.
/cgo/go-to-c-calls:calls metric reports the total
- number of calls made from Go to C. This metric is identical to the runtime.NumCgoCall
+ The new /cgo/go-to-c-calls:calls
+ metric
+ reports the total number of calls made from Go to C. This metric is
+ identical to the
+ runtime.NumCgoCall
function.
/gc/limiter/last-enabled:gc-cycle metric reports the
- last GC cycle when the GC CPU limiter was enabled.
+ The new /gc/limiter/last-enabled:gc-cycle
+ metric
+ reports the last GC cycle when the GC CPU limiter was enabled. See the
+ runtime notes for details about the GC CPU limiter.
ResponseWriter.WriteHeader
+ now supports sending user-defined 1xx informational headers.
io.ReadCloser returned by
+ MaxBytesReader
+ will now return the defined error type
+ MaxBytesError
+ when its read limit is exceeded.
+ Location header by returning it to the caller,
+ rather than treating it as an error.
JoinPath
+ function and
+ URL.JoinPath
+ method create a new URL by joining a list of path
+ elements.
URL type now distinguishes between URLs with no
+ authority and URLs with an empty authority. For example,
+ http:///path has an empty authority (host),
+ while http:/path has none.
+ URL field
+ OmitHost is set to true when a
+ URL has an empty authority.
- TODO: complete this section, or delete if not needed +
+ On ELF platforms, the linker now emits compressed DWARF sections in
+ the standard gABI format (SHF_COMPRESSED), instead of
+ the legacy .zdebug format.
+ Like the compiler, the assembler now requires the
+ -p=importpath flag to build a linkable object file.
+ This is already supplied by the go command. Any other
+ build systems that invoke the Go assembler directly will need to
+ make sure they pass this flag as well.
+
On ELF platforms, the linker now emits compressed DWARF sections in
From a7551fe24524fb960fbe4cd74dae13afe9ca6a5c Mon Sep 17 00:00:00 2001
From: Damien Neil GOARCH=amd64 and GOARCH=arm64 only)
- TODO: https://go.dev/cl/402374: enable regabi on riscv64 by default
+ The riscv64 port now supports passing function arguments
+ and result using registers. Benchmarking shows typical performance
+ improvements of 10% or more on riscv64.
The Go compiler now requires the -p=importpath flag to
From 2882786bf4cd779f166e9ced82a4da2ea0f8b1f9 Mon Sep 17 00:00:00 2001
From: Tobias Klauser
- TODO: complete this section -
- TODO: https://go.dev/issue/52038: adjust scope of type parameters declared by method receivers + There is only one small change to the language, + a very small correction + to the scope of type parameters in method declarations. + Existing programs are unaffected. +
+ +
+ The Go memory model has been revised to align Go with
+ the memory model used by C, C++, Java, JavaScript, Rust, and Swift.
+ Go only provides sequentially consistent atomics, not any of the more relaxed forms found in other languages.
+ Along with the memory model update,
+ Go 1.19 introduces new types in the sync/atomic package
+ that make it easier to use atomic values, such as
+ atomic.Int64
+ and
+ atomic.Pointer[T].
- TODO: complete this section, or delete if not needed -
-: - TODO: https://go.dev/issue/47528 warn when errors.As target has type *error -
- TODO: complete this section. + +
+Go 1.19 adds support for links, lists, and clearer headings in doc comments.
+As part of this change, gofmt
+now reformats doc comments to make their rendered meaning clearer.
+See “Go Doc Comments”
+for syntax details and descriptions of common mistakes now highlighted by gofmt.
+As another part of this change, the new package go/doc/comment
+provides parsing and reformatting of doc comments
+as well as support for rendering them to HTML, Markdown, and text.
+
unix build constraint
+
+
+ The build constraint unix is now recognized
+ in //go:build lines. The constraint is satisfied
+ if the target operating system, also known as GOOS, is
+ a Unix or Unix-like system. For the 1.19 release it is satisfied
+ if GOOS is one of
+ aix, android, darwin,
+ dragonfly, freebsd, hurd,
+ illumos, ios, linux,
+ netbsd, openbsd, or solaris.
+ In future releases the unix constraint may match
+ additional newly supported operating systems.
GOGCCFLAGS variables it reports.
+unix build constraint
- The build constraint unix is now recognized
- in //go:build lines. The constraint is satisfied
- if the target operating system, also known as GOOS, is
- a Unix or Unix-like system. For the 1.19 release it is satisfied
- if GOOS is one of
- aix, android, darwin,
- dragonfly, freebsd, hurd,
- illumos, ios, linux,
- netbsd, openbsd, or solaris.
- In future releases the unix constraint may match
- additional newly supported operating systems.
+
:
+ The vet checker “errorsas” now reports when
+ errors.As is called
+ with a second argument of type *error,
+ a common mistake.
+
On Unix operating systems, Go programs that import package
os now automatically increase the open file limit
- (RLIMIT_NOFILE) to the maximum allowed value. Programs that need
- a lower limit (for compatibility with select, for example) can
- set the limit back as needed, or lower the hard limit prior to starting the
- Go program.
+ (RLIMIT_NOFILE) to the maximum allowed value;
+ that is, they change the soft limit to match the hard limit.
+ This corrects artificially low limits set on some systems for compatibility with very old C programs using the
+ select system call.
+ Go programs are not helped by that limit, and instead even simple programs like gofmt
+ often ran out of file descriptors on such systems when processing many files in parallel.
+ One impact of this change is that Go programs that in turn execute very old C programs in child processes
+ may run those programs with too high a limit.
+ This can be corrected by setting the hard limit before invoking the Go program.
@@ -174,7 +203,8 @@ Do not send CLs removing the interior tags from such phrases.
- TODO: https://go.dev/issue/44853: enable address sanitizer in Go + The address sanitizer support added in Go 1.18 + now handles function arguments and global variables more precisely.
- TODO: complete this section -
-
The sync/atomic package defines new atomic types
Bool,
@@ -238,46 +265,46 @@ Do not send CLs removing the interior tags from such phrases.
the need to convert to
unsafe.Pointer at call sites.
Int64 and
- Uint64 automatically
- receive 64-bit alignment on ARM, 386, and 32-bit MIPS required for 64-bit
- atomics on these systems.
-
- TODO: https://go.dev/cl/384265: go/doc: use go/doc/comment; modified api/next/51082.txt
- TODO: https://go.dev/cl/397276: go/doc/comment: add data structures; modified api/next/51082.txt
- TODO: https://go.dev/cl/397278: go/doc/comment: add paragraph parsing and test framework; modified api/next/51082.txt
- TODO: https://go.dev/cl/397279: go/doc/comment: add Printer and basic comment printing; modified api/next/51082.txt
- TODO: https://go.dev/cl/397281: go/doc/comment: parse and print doc links; modified api/next/51082.txt
- TODO: https://go.dev/cl/397284: go/doc/comment: parse and print headings; modified api/next/51082.txt
+ Uint64 are
+ automatically aligned to 64-bit boundaries in structs and allocated data,
+ even on 32-bit systems.
- TODO: https://go.dev/issue/43724: return error when PATH lookup would use current directory -
-- TODO: https://go.dev/issue/43947: on Windows use NeedCurrentDirectoryForExePathW for LookPath behavior +
+
+ Command and
+ LookPath no longer
+ allow results from a PATH search to be found relative to the current directory.
+ This removes a common source of security problems
+ but may also break existing programs that depend on using, say, exec.Command("prog")
+ to run a binary named prog (or, on Windows, prog.exe) in the current directory.
+ See the os/exec package documentation for
+ information about how best to update such programs.
+ On Windows, Command and LookPath now respect the
+ NoDefaultCurrentDirectoryInExePath
+ environment variable, making it possible to disable
+ the default implicit search of “.” in PATH lookups on Windows systems.
+
As always, there are various minor changes and updates to the library, made with the Go 1 promise of compatibility in mind. -
-- TODO: complete this section + There are also various performance improvements, not enumerated here.
- TODO: https://go.dev/cl/387976: permit zip files to have prefixes
+ Reader
+ now ignores non-ZIP data at the start of a ZIP file, matching most other implementations.
+ This is necessary to read some Java JAR files, among other uses.
- CreateCertificate
- no longer supports creating certificates with SignatureAlgorithm
+ CreateCertificate
+ no longer supports creating certificates with SignatureAlgorithm
set to MD5WithRSA.
RevocationList adds new fields
RawIssuer, Signature,
AuthorityKeyId, and Extensions.
-
- The new method RevocationList.CheckSignatureFrom
+
+ The new method RevocationList.CheckSignatureFrom
checks that the signature on a CRL is a valid signature from a
Certificate.
@@ -358,7 +385,7 @@ Do not send CLs removing the interior tags from such phrases.
When building paths, Certificate.Verify
- now considers certificates to be equal when the subjects, public keys, and SANs
+ now considers certificates to be equal when the subjects, public keys, and SANs
are all equal. Before, it required byte-for-byte equality.
- TODO: https://go.dev/cl/396735: debug: define ELF relocation for loong64; modified api/next/46229.txt
+ The new EM_LONGARCH and R_LARCH_* constants
+ support the loong64 port.
- TODO: https://go.dev/issue/51868: add APIs to support reading COMDAT info for sections -
- -- TODO: https://go.dev/cl/394534: debug/pe: add APIs for reading section def aux info; modified api/next/51868.txt +
+ The new File.COFFSymbolReadSectionDefAux
+ method, which returns a COFFSymbolAuxFormat5,
+ provides access to COMDAT information in PE file sections.
+ These are supported by new IMAGE_COMDAT_* and IMAGE_SCN_* constants.
- TODO: https://go.dev/cl/386017: add AppendByteOrder
+ The new interface
+ AppendByteOrder
+ provides efficient methods for appending a uint16, uint32, or uint64
+ to a byte slice.
+ BigEndian and
+ LittleEndian now implement this interface.
- TODO: https://go.dev/issue/51644: add AppendUvarint and AppendVarint
+ Similarly, the new functions
+ AppendUvarint and
+ AppendVarint
+ are efficient appending versions of
+ PutUvarint and
+ PutVarint.
- TODO: https://go.dev/cl/405675: add Reader.InputOffset method
+ The new method
+ Reader.InputOffset
+ reports the reader's current input position as a byte offset,
+ analogous to encoding/json's
+ Decoder.InputOffset.
- TODO: https://go.dev/issue/45628: add Decoder.InputPos
- TODO: https://go.dev/cl/311270: encoding/xml: expose decoder line and column; modified api/next/45628.txt
+ The new method
+ Decoder.InputPos
+ reports the reader's current input position as a line and column,
+ analogous to encoding/csv's
+ Decoder.FieldPos.
- TODO: https://go.dev/cl/313329: add TextVar function
+ The new function
+ TextVar
+ defines a flag with a value implementing
+ encoding.TextUnmarshaler,
+ allowing command-line flag variables to have types such as
+ big.Int,
+ netip.Addr, and
+ time.Time.
- TODO: https://go.dev/cl/406177: add Append, Appendln, Appendf
+ The new functions
+ Append,
+ Appendf, and
+ Appendln
+ append formatted data to byte slices.
- TODO: https://go.dev/cl/403696: parser to accept ~x as unary expression
+ The parser now recognizes ~x as a unary expression with operator
+ token.TILDE,
+ allowing better error recovery when a type constraint such as ~int is used in an incorrect context.
- TODO: https://go.dev/cl/392494: hash/maphash: add Bytes and String; modified api/next/42710.txt
- TODO: https://go.dev/issue/42710: add Bytes and String
+ The new functions
+ Bytes
+ and
+ String
+ provide an efficient way hash a single byte slice or string.
+ They are equivalent to using the more general
+ Hash
+ with a single write, but they avoid setup overhead for small inputs.
- TODO: https://go.dev/issue/46121: make FuncMap an alias for text/template.FuncMap
- TODO: https://go.dev/cl/389156: html/template: make FuncMap a type alias of text/template.FuncMap; modified api/except.txt, api/next/46121.txt
+ The type FuncMap
+ is now an alias for
+ text/template's FuncMap
+ instead of its own named type.
+ This allows writing code that operates on a FuncMap from either setting.
- Draw with the Src operator preserves
+ Draw with the
+ Src operator preserves
non-premultiplied-alpha colors when destination and source images are
- both *image.NRGBA (or both *image.NRGBA64).
+ both image.NRGBA
+ or both image.NRGBA64.
This reverts a behavior change accidentally introduced by a Go 1.18
- library optimization, to match the behavior in Go 1.17 and earlier.
+ library optimization; the code now matches the behavior in Go 1.17 and earlier.
- TODO: https://go.dev/cl/400236: NopCloser forward WriterTo implementations if the reader supports it
+ NopCloser's result now implements
+ WriterTo
+ whenever its input does.
- TODO: https://go.dev/issue/50842: implement WriterTo on result of MultiReader
+ MultiReader's result now implements
+ WriterTo unconditionally.
+ If any underlying reader does not implement WriterTo,
+ it is simulated appropriately.
text/javascript; charset=utf-8.
Applications that expect text/plain on Windows must
now explicitly call
- AddExtensionType.
+ AddExtensionType.
Resolver.PreferGo
is now implemented on Windows and Plan 9. It previously only worked on Unix
@@ -578,6 +651,7 @@ Do not send CLs removing the interior tags from such phrases.
possible to write portable programs and be in control of all DNS name lookups
when dialing.
The net package now has initial support for the netgo
build tag on Windows. When used, the package uses the Go DNS client (as used
@@ -636,26 +710,17 @@ Do not send CLs removing the interior tags from such phrases.
-
- TODO: https://go.dev/cl/392415: raise open file rlimit at startup -
-
- An exec.Cmd with a non-empty Dir and a
- nil Env now implicitly sets the PWD environment
+ A Cmd with a non-empty Dir field
+ and nil Env now implicitly sets the PWD environment
variable for the subprocess to match Dir.
- The new method (*exec.Cmd).Environ reports the
+ The new method Cmd.Environ reports the
environment that would be used to run the command, including the
- aforementioned PWD variable.
+ implicitly set PWD variable.
- The method Value.Bytes now accepts addressable arrays in addition to slices.
+ The method Value.Bytes
+ now accepts addressable arrays in addition to slices.
- The methods Value.Len and Value.Cap now successfully operate on a pointer to an array and return the length of that array, to match what the builtin len and cap functions do.
+ The methods Value.Len
+ and Value.Cap
+ now successfully operate on a pointer to an array and return the length of that array,
+ to match what the builtin
+ len and cap functions do.
- TODO: https://go.dev/issue/51684: add ErrNestingDepth error
- TODO: https://go.dev/cl/401076: regexp: change ErrInvalidDepth message to match proposal; modified api/next/51684.txt, api/next/regexpdepth.txt
+ Go 1.18 release candidate 1, Go 1.17.8, and Go 1.16.15 included a security fix
+ to the regular expression parser, making it reject very deeply nested expressions.
+ Because Go patch releases do not introduce new API,
+ the parser returned syntax.ErrInternalError in this case.
+ Go 1.19 adds a more specific error, syntax.ErrNestingDepth,
+ which the parser now returns instead.
- TODO: https://go.dev/cl/384617: regexp/syntax: add and use ErrInvalidDepth; modified api/next/regexpdepth.txt - TODO: https://go.dev/cl/401854: regexp/syntax: rename ErrInvalidDepth to ErrNestingDepth; modified api/next/51684.txt -
-
- The GOROOT function now returns the empty string
+ The GOROOT function now returns the empty string
(instead of "go") when the binary was built with
the -trimpath flag set and the GOROOT
variable is not set in the process environment.
@@ -797,8 +861,11 @@ Do not send CLs removing the interior tags from such phrases.
is faster for several common scenarios.
- TODO: https://go.dev/issue/50340: add Find - TODO: https://go.dev/cl/396514: sort: add Find function; modified api/next/50340.txt + The new function + Find + is like + Search + but often easier to use: it returns an additional boolean reporting whether an equal value was found.
Quote
- and related functions now quote the rune 007F as \x7f,
- not \u007f.
+ and related functions now quote the rune U+007F as \x7f,
+ not \u007f,
+ for consistency with other ASCII values.
- TODO: https://go.dev/cl/393515: add Duration.Abs
- TODO: https://go.dev/issue/51414: add Duration.Abs
+ The new method
+ Duration.Abs
+ provides a convenient and safe way to take the absolute value of a duration,
+ converting −2⁶³ to 2⁶³−1.
+ (This boundary case can happen as the result of subtracting a recent time from the zero time.)
- TODO: https://go.dev/issue/50062: add Time.ZoneBounds
- TODO: https://go.dev/cl/405374: time: add Time.ZoneBounds; modified api/next/50062.txt
+ The new method
+ Time.ZoneBounds
+ returns the start and end times of the time zone in effect at a given time.
+ It can be used in a loop to enumerate all the known time zone transitions at a given location.
- TODO: complete this section, or delete if not needed -
+
Go 1.19 supports the Loongson 64-bit architecture LoongArch on Linux (GOOS=linux, GOARCH=loong64).
- TODO: complete this section. -
@@ -357,14 +352,14 @@ as well as support for rendering them to HTML, Markdown, and text. now reject certificates and CSRs which contain duplicate extensions.
-+
The new CertPool.Clone
and CertPool.Equal
methods allow cloning a CertPool and checking the equality of two
CertPools respectively.
+
The new function ParseRevocationList
provides a faster, safer to use CRL parser which returns a
RevocationList.
@@ -388,23 +383,6 @@ as well as support for rendering them to HTML, Markdown, and text.
now considers certificates to be equal when the subjects, public keys, and SANs
are all equal. Before, it required byte-for-byte equality.
- TODO: https://go.dev/issue/46057: add CertPool.Equal -
- -- TODO: https://go.dev/issue/50674: add ParseRevocationList, deprecate ParseCRL & ParseDERCRL -
- -- TODO: https://go.dev/cl/390834: crypto/x509: add new CRL parser, deprecate old one; modified api/next/50674.txt -
- -- TODO: https://go.dev/cl/400175: crypto/x509: add CertPool.Clone; modified api/next/35044.txt - TODO: https://go.dev/issue/35044: add CertPool.Clone -
- TODO: https://go.dev/cl/397018: runtime/debug: export SetMemoryLimit; modified api/next/48409.txt -
-
From d65166024f3969289be5c74fd8be7d06a93264f1 Mon Sep 17 00:00:00 2001
From: Michael Matloob
@@ -205,7 +205,7 @@ by other languages, including C, C++, Java, JavaScript, Rust, and Swift.
Certain Go language operations such as goroutine creation and memory allocation
-act as synchronization opeartions.
+act as synchronization operations.
The effect of these operations on the synchronized-before partial order
is documented in the “Synchronization” section below.
Individual packages are responsible for providing similar documentation
From 55590f3a2b89f001bcadf0df6eb2dde62618302b Mon Sep 17 00:00:00 2001
From: Louis PORTAY
The types tag, and tags a type that was untagged.
Change-Id: I9a1efda07f783f0ca7a93ffefbda4e29f5fc8d41
Reviewed-on: https://go-review.googlesource.com/c/go/+/411694
Auto-Submit: Roland Shoemaker CRL functionality
+ have been deprecated. The new RawIssuer, Signature,
AuthorityKeyId, and Extensions.
- The new method RevocationList.CheckSignatureFrom
+ The new method RevocationList.CheckSignatureFrom
checks that the signature on a CRL is a valid signature from a
- Certificate.
+ Certificate.
With the new CRL functionality, the existing functions
ParseCRL and
@@ -391,7 +391,7 @@ as well as support for rendering them to HTML, Markdown, and text.
CertificateList and
TBSCertificateList
- have been deprecated. The new crypto/x509crypto/x509 CRL functionality
should be used instead.
GOGCCFLAGS variables it reports.
+
+ The go command now caches information necessary to load some modules,
+ which should result in a speed-up of some go list invocations.
+
:
From 2c52465cb3d327590755cfb9ef1ef0f7a167c4eb Mon Sep 17 00:00:00 2001
From: Damien Neil
StructType = "struct" "{" { FieldDecl ";" } "}" .
FieldDecl = (IdentifierList Type | EmbeddedField) [ Tag ] .
-EmbeddedField = [ "*" ] TypeName .
+EmbeddedField = [ "*" ] TypeName [ TypeArgs ] .
Tag = string_lit .
@@ -3029,7 +3029,7 @@ Each element may optionally be preceded by a corresponding key.
CompositeLit = LiteralType LiteralValue .
LiteralType = StructType | ArrayType | "[" "..." "]" ElementType |
- SliceType | MapType | TypeName .
+ SliceType | MapType | TypeName [ TypeArgs ] .
LiteralValue = "{" [ ElementList [ "," ] ] "}" .
ElementList = KeyedElement { "," KeyedElement } .
KeyedElement = [ Key ":" ] Element .
From 5ee939b8199266446d7ccc563751a9d3db26bf8b Mon Sep 17 00:00:00 2001
From: Robert Griesemer int; if it is an untyped constant it is given type int.
If both n and m are provided and are constant, then
n must be no larger than m.
-If n is negative or larger than m at run time,
+For slices and channels, if n is negative or larger than m at run time,
a run-time panic occurs.
GOGC,
and will be respected even if GOGC=off, allowing Go programs to
always make maximal use of their memory limit, improving resource efficiency
- in some cases. See the GC guide for
+ in some cases. See the GC guide for
a detailed guide explaining the soft memory limit in more detail, as well as
a variety of common use-cases and scenarios. Please note that small memory
limits, on the order of tens of megabytes or less, are less likely to be
@@ -277,7 +277,7 @@ as well as support for rendering them to HTML, Markdown, and text.
Command and
LookPath no longer
allow results from a PATH search to be found relative to the current directory.
- This removes a common source of security problems
+ This removes a common source of security problems
but may also break existing programs that depend on using, say, exec.Command("prog")
to run a binary named prog (or, on Windows, prog.exe) in the current directory.
See the os/exec package documentation for
@@ -718,7 +718,7 @@ as well as support for rendering them to HTML, Markdown, and text.
The methods Value.Len
and Value.Cap
now successfully operate on a pointer to an array and return the length of that array,
- to match what the builtin
+ to match what the builtin
len and cap functions do.
From 6130461149020d2b4b91fb183afa388a211cadc5 Mon Sep 17 00:00:00 2001
From: Michael Anthony Knyszek
- Go 1.19 supports the Loongson 64-bit architecture LoongArch on Linux (GOOS=linux, GOARCH=loong64).
+ Go 1.19 adds support for the Loongson 64-bit architecture LoongArch
+ on Linux (GOOS=linux, GOARCH=loong64).
+
+ The riscv64 port now supports passing function arguments
+ and result using registers. Benchmarking shows typical performance
+ improvements of 10% or more on riscv64.
: +
The vet checker “errorsas” now reports when
errors.As is called
with a second argument of type *error,
@@ -217,11 +226,6 @@ as well as support for rendering them to HTML, Markdown, and text.
on the order of 20% faster.
(GOARCH=amd64 and GOARCH=arm64 only)
- The riscv64 port now supports passing function arguments
- and result using registers. Benchmarking shows typical performance
- improvements of 10% or more on riscv64.
-
The Go compiler now requires the -p=importpath flag to
build a linkable object file. This is already supplied by
From c29be2d41c6c3ed78a76b4d8d8c1c22d7e0ad5b7 Mon Sep 17 00:00:00 2001
From: Austin Clements "\uFFFD".
string('a') // "a"
string(-1) // "\ufffd" == "\xef\xbf\xbd"
string(0xf8) // "\u00f8" == "ø" == "\xc3\xb8"
-type MyString string
-MyString(0x65e5) // "\u65e5" == "日" == "\xe6\x97\xa5"
+
+type myString string
+myString(0x65e5) // "\u65e5" == "日" == "\xe6\x97\xa5"
@@ -5442,8 +5443,12 @@ string([]byte{'h', 'e', 'l', 'l', '\xc3', '\xb8'}) // "hellø"
string([]byte{}) // ""
string([]byte(nil)) // ""
-type MyBytes []byte
-string(MyBytes{'h', 'e', 'l', 'l', '\xc3', '\xb8'}) // "hellø"
+type bytes []byte
+string(bytes{'h', 'e', 'l', 'l', '\xc3', '\xb8'}) // "hellø"
+
+type myByte byte
+string([]myByte{'w', 'o', 'r', 'l', 'd', '!'}) // "world!"
+myString([]myByte{'\xf0', '\x9f', '\x8c', '\x8d'}) // "🌍"
@@ -5457,8 +5462,12 @@ string([]rune{0x767d, 0x9d6c, 0x7fd4}) // "\u767d\u9d6c\u7fd4" == "白鵬翔"
string([]rune{}) // ""
string([]rune(nil)) // ""
-type MyRunes []rune
-string(MyRunes{0x767d, 0x9d6c, 0x7fd4}) // "\u767d\u9d6c\u7fd4" == "白鵬翔"
+type runes []rune
+string(runes{0x767d, 0x9d6c, 0x7fd4}) // "\u767d\u9d6c\u7fd4" == "白鵬翔"
+
+type myRune rune
+string([]myRune{0x266b, 0x266c}) // "\u266b\u266c" == "♫♬"
+myString([]myRune{0x1F30E}) // "\U0001f30e" == "🌎"
@@ -5467,10 +5476,13 @@ Converting a value of a string type to a slice of bytes type
yields a slice whose successive elements are the bytes of the string.
-[]byte("hellø") // []byte{'h', 'e', 'l', 'l', '\xc3', '\xb8'}
-[]byte("") // []byte{}
+[]byte("hellø") // []byte{'h', 'e', 'l', 'l', '\xc3', '\xb8'}
+[]byte("") // []byte{}
-MyBytes("hellø") // []byte{'h', 'e', 'l', 'l', '\xc3', '\xb8'}
+bytes("hellø") // []byte{'h', 'e', 'l', 'l', '\xc3', '\xb8'}
+
+[]myByte("world!") // []myByte{'w', 'o', 'r', 'l', 'd', '!'}
+[]myByte(myString("🌏")) // []myByte{'\xf0', '\x9f', '\x8c', '\x8f'}
@@ -5479,10 +5491,13 @@ Converting a value of a string type to a slice of runes type
yields a slice containing the individual Unicode code points of the string.
-[]rune(MyString("白鵬翔")) // []rune{0x767d, 0x9d6c, 0x7fd4}
-[]rune("") // []rune{}
+[]rune(myString("白鵬翔")) // []rune{0x767d, 0x9d6c, 0x7fd4}
+[]rune("") // []rune{}
-MyRunes("白鵬翔") // []rune{0x767d, 0x9d6c, 0x7fd4}
+runes("白鵬翔") // []rune{0x767d, 0x9d6c, 0x7fd4}
+
+[]myRune("♫♬") // []myRune{0x266b, 0x266c}
+[]myRune(myString("🌐")) // []myRune{0x1f310}
From f9c0264107a9a36832d70781fe100cff16917855 Mon Sep 17 00:00:00 2001
From: Ian Lance Taylor
unix build constraint
+unix build constraint
The build constraint
-All other sequences starting with a backslash are illegal inside rune literals.
+An unrecognized character following a backslash in a rune literal is illegal.
unix is now recognized
From 74bf90c779b3d4a4babd3e3de38e3d3e5d9dd7de Mon Sep 17 00:00:00 2001
From: Robert Griesemer
rune_lit = "'" ( unicode_value | byte_value ) "'" .
unicode_value = unicode_char | little_u_value | big_u_value | escaped_char .
@@ -530,6 +531,7 @@ escaped_char = `\` ( "a" | "b" | "f" | "n" | "r" | "t" | "v" | `\` | "'" | `
'\U00101234'
'\'' // rune literal containing single quote character
'aa' // illegal: too many characters
+'\k' // illegal: k is not recognized after a backslash
'\xa' // illegal: too few hexadecimal digits
'\0' // illegal: too few octal digits
'\400' // illegal: octal value over 255
From 1d9d99b7ce279f2af928f79cbc5906d99f29bb67 Mon Sep 17 00:00:00 2001
From: Cherry Mui