"Fossies" - the Fresh Open Source Software Archive

Member "go/doc/go1.14.html" (9 Sep 2020, 35964 Bytes) of package /windows/misc/go1.14.9.windows-386.zip:


As a special service "Fossies" has tried to format the requested source page into HTML format using (guessed) HTML source code syntax highlighting (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 <!--{
    2         "Title": "Go 1.14 Release Notes",
    3         "Path":  "/doc/go1.14"
    4 }-->
    5 
    6 <!--
    7 NOTE: In this document and others in this directory, the convention is to
    8 set fixed-width phrases with non-fixed-width spaces, as in
    9 <code>hello</code> <code>world</code>.
   10 Do not send CLs removing the interior tags from such phrases.
   11 -->
   12 
   13 <style>
   14   main ul li { margin: 0.5em 0; }
   15 </style>
   16 
   17 <h2 id="introduction">Introduction to Go 1.14</h2>
   18 
   19 <p>
   20   The latest Go release, version 1.14, arrives six months after <a href="go1.13">Go 1.13</a>.
   21   Most of its changes are in the implementation of the toolchain, runtime, and libraries.
   22   As always, the release maintains the Go 1 <a href="/doc/go1compat.html">promise of compatibility</a>.
   23   We expect almost all Go programs to continue to compile and run as before.
   24 </p>
   25 
   26 <p>
   27   Module support in the <code>go</code> command is now ready for production use,
   28   and we encourage all users to <a href="https://blog.golang.org/migrating-to-go-modules">migrate to Go
   29   modules for dependency management</a>. If you are unable to migrate due to a problem in the Go
   30   toolchain, please ensure that the problem has an
   31   <a href="https://golang.org/issue?q=is%3Aissue+is%3Aopen+label%3Amodules">open issue</a>
   32   filed. (If the issue is not on the <code>Go1.15</code> milestone, please let us
   33   know why it prevents you from migrating so that we can prioritize it
   34   appropriately.)
   35 </p>
   36 
   37 <h2 id="language">Changes to the language</h2>
   38 
   39 <p>
   40   Per the <a href="https://github.com/golang/proposal/blob/master/design/6977-overlapping-interfaces.md">overlapping interfaces proposal</a>,
   41   Go 1.14 now permits embedding of interfaces with overlapping method sets:
   42   methods from an embedded interface may have the same names and identical signatures
   43   as methods already present in the (embedding) interface. This solves problems that typically
   44   (but not exclusively) occur with diamond-shaped embedding graphs.
   45   Explicitly declared methods in an interface must remain
   46   <a href="https://tip.golang.org/ref/spec#Uniqueness_of_identifiers">unique</a>, as before.
   47 </p>
   48 
   49 <h2 id="ports">Ports</h2>
   50 
   51 <h3 id="darwin">Darwin</h3>
   52 
   53 <p>
   54   Go 1.14 is the last release that will run on macOS 10.11 El Capitan.
   55   Go 1.15 will require macOS 10.12 Sierra or later.
   56 </p>
   57 
   58 <p><!-- golang.org/issue/34749 -->
   59   Go 1.14 is the last Go release to support 32-bit binaries on
   60   macOS (the <code>darwin/386</code> port). They are no longer
   61   supported by macOS, starting with macOS 10.15 (Catalina).
   62   Go continues to support the 64-bit <code>darwin/amd64</code> port.
   63 </p>
   64 
   65 <p><!-- golang.org/issue/34751 -->
   66   Go 1.14 will likely be the last Go release to support 32-bit
   67   binaries on iOS, iPadOS, watchOS, and tvOS
   68   (the <code>darwin/arm</code> port). Go continues to support the
   69   64-bit <code>darwin/arm64</code> port.
   70 </p>
   71 
   72 <h3 id="windows">Windows</h3>
   73 
   74 <p><!-- CL 203601 -->
   75   Go binaries on Windows now
   76   have <a href="https://docs.microsoft.com/en-us/windows/win32/memory/data-execution-prevention">DEP
   77   (Data Execution Prevention)</a> enabled.
   78 </p>
   79 
   80 <p><!-- CL 202439 -->
   81   On Windows, creating a file
   82   via <a href="/pkg/os#CreateFile"><code>os.OpenFile</code></a> with
   83   the <a href="/pkg/os/#O_CREATE"><code>os.O_CREATE</code></a> flag, or
   84   via <a href="/pkg/syscall#Open"><code>syscall.Open</code></a> with
   85   the <a href="/pkg/syscall#O_CREAT"><code>syscall.O_CREAT</code></a>
   86   flag, will now create the file as read-only if the
   87   bit <code>0o200</code> (owner write permission) is not set in the
   88   permission argument. This makes the behavior on Windows more like
   89   that on Unix systems.
   90 </p>
   91 
   92 <h3 id="wasm">WebAssembly</h3>
   93 
   94 <p><!-- CL 203600 -->
   95   JavaScript values referenced from Go via <code>js.Value</code>
   96   objects can now be garbage collected.
   97 </p>
   98 
   99 <p><!-- CL 203600 -->
  100   <code>js.Value</code> values can no longer be compared using
  101   the <code>==</code> operator, and instead must be compared using
  102   their <code>Equal</code> method.
  103 </p>
  104 
  105 <p><!-- CL 203600 -->
  106   <code>js.Value</code> now
  107   has <code>IsUndefined</code>, <code>IsNull</code>,
  108   and <code>IsNaN</code> methods.
  109 </p>
  110 
  111 <h3 id="riscv">RISC-V</h3>
  112 
  113 <p><!-- Issue 27532 -->
  114   Go 1.14 contains experimental support for 64-bit RISC-V on Linux
  115   (<code>GOOS=linux</code>, <code>GOARCH=riscv64</code>). Be aware
  116   that performance, assembly syntax stability, and possibly
  117   correctness are a work in progress.
  118 </p>
  119 
  120 <h3 id="freebsd">FreeBSD</h3>
  121 
  122 <p><!-- CL 199919 -->
  123   Go now supports the 64-bit ARM architecture on FreeBSD 12.0 or later (the
  124   <code>freebsd/arm64</code> port).
  125 </p>
  126 
  127 <h3 id="nacl">Native Client (NaCl)</h3>
  128 
  129 <p><!-- golang.org/issue/30439 -->
  130   As <a href="go1.13#ports">announced</a> in the Go 1.13 release notes,
  131   Go 1.14 drops support for the Native Client platform (<code>GOOS=nacl</code>).
  132 </p>
  133 
  134 <h3 id="illumos">Illumos</h3>
  135 
  136 <p><!-- CL 203758 -->
  137   The runtime now respects zone CPU caps
  138   (the <code>zone.cpu-cap</code> resource control)
  139   for <code>runtime.NumCPU</code> and the default value
  140   of <code>GOMAXPROCS</code>.
  141 </p>
  142 
  143 <h2 id="tools">Tools</h2>
  144 
  145 <h3 id="go-command">Go command</h3>
  146 
  147 <h4 id="vendor">Vendoring</h4>
  148 <!-- golang.org/issue/33848 -->
  149 
  150 <p>
  151   When the main module contains a top-level <code>vendor</code> directory and
  152   its <code>go.mod</code> file specifies <code>go</code> <code>1.14</code> or
  153   higher, the <code>go</code> command now defaults to <code>-mod=vendor</code>
  154   for operations that accept that flag. A new value for that flag,
  155   <code>-mod=mod</code>, causes the <code>go</code> command to instead load
  156   modules from the module cache (as when no <code>vendor</code> directory is
  157   present).
  158 </p>
  159 
  160 <p>
  161   When <code>-mod=vendor</code> is set (explicitly or by default), the
  162   <code>go</code> command now verifies that the main module's
  163   <code>vendor/modules.txt</code> file is consistent with its
  164   <code>go.mod</code> file.
  165 </p>
  166 
  167 <p>
  168   <code>go</code> <code>list</code> <code>-m</code> no longer silently omits
  169   transitive dependencies that do not provide packages in
  170   the <code>vendor</code> directory. It now fails explicitly if
  171   <code>-mod=vendor</code> is set and information is requested for a module not
  172   mentioned in <code>vendor/modules.txt</code>.
  173 </p>
  174 
  175 <h4 id="go-flags">Flags</h4>
  176 
  177 <p><!-- golang.org/issue/32502, golang.org/issue/30345 -->
  178   The <code>go</code> <code>get</code> command no longer accepts
  179   the <code>-mod</code> flag. Previously, the flag's setting either
  180   <a href="https://golang.org/issue/30345">was ignored</a> or
  181   <a href="https://golang.org/issue/32502">caused the build to fail</a>.
  182 </p>
  183 
  184 <p><!-- golang.org/issue/33326 -->
  185   <code>-mod=readonly</code> is now set by default when the <code>go.mod</code>
  186   file is read-only and no top-level <code>vendor</code> directory is present.
  187 </p>
  188 
  189 <p><!-- golang.org/issue/31481 -->
  190   <code>-modcacherw</code> is a new flag that instructs the <code>go</code>
  191   command to leave newly-created directories in the module cache at their
  192   default permissions rather than making them read-only.
  193   The use of this flag makes it more likely that tests or other tools will
  194   accidentally add files not included in the module's verified checksum.
  195   However, it allows the use of <code>rm</code> <code>-rf</code>
  196   (instead of <code>go</code> <code>clean</code> <code>-modcache</code>)
  197   to remove the module cache.
  198 </p>
  199 
  200 <p><!-- golang.org/issue/34506 -->
  201   <code>-modfile=file</code> is a new flag that instructs the <code>go</code>
  202   command to read (and possibly write) an alternate <code>go.mod</code> file
  203   instead of the one in the module root directory. A file
  204   named <code>go.mod</code> must still be present in order to determine the
  205   module root directory, but it is not accessed. When <code>-modfile</code> is
  206   specified, an alternate <code>go.sum</code> file is also used: its path is
  207   derived from the <code>-modfile</code> flag by trimming the <code>.mod</code>
  208   extension and appending <code>.sum</code>.
  209 </p>
  210 
  211 <h4 id="go-env-vars">Environment variables</h4>
  212 
  213 <p><!-- golang.org/issue/32966 -->
  214   <code>GOINSECURE</code> is a new environment variable that instructs
  215   the <code>go</code> command to not require an HTTPS connection, and to skip
  216   certificate validation, when fetching certain modules directly from their
  217   origins. Like the existing <code>GOPRIVATE</code> variable, the value
  218   of <code>GOINSECURE</code> is a comma-separated list of glob patterns.
  219 </p>
  220 
  221 <h4 id="commands-outside-modules">Commands outside modules</h4>
  222 
  223 <p><!-- golang.org/issue/32027 -->
  224   When module-aware mode is enabled explicitly (by setting
  225   <code>GO111MODULE=on</code>), most module commands have more
  226   limited functionality if no <code>go.mod</code> file is present. For
  227   example, <code>go</code> <code>build</code>,
  228   <code>go</code> <code>run</code>, and other build commands can only build
  229   packages in the standard library and packages specified as <code>.go</code>
  230   files on the command line.
  231 </p>
  232 
  233 <p>
  234   Previously, the <code>go</code> command would resolve each package path
  235   to the latest version of a module but would not record the module path
  236   or version. This resulted in <a href="https://golang.org/issue/32027">slow,
  237   non-reproducible builds</a>.
  238 </p>
  239 
  240 <p>
  241   <code>go</code> <code>get</code> continues to work as before, as do
  242   <code>go</code> <code>mod</code> <code>download</code> and
  243   <code>go</code> <code>list</code> <code>-m</code> with explicit versions.
  244 </p>
  245 
  246 <h4 id="incompatible-versions"><code>+incompatible</code> versions</h4>
  247 <!-- golang.org/issue/34165 -->
  248 
  249 <p>
  250   If the latest version of a module contains a <code>go.mod</code> file,
  251   <code>go</code> <code>get</code> will no longer upgrade to an
  252   <a href="/cmd/go/#hdr-Module_compatibility_and_semantic_versioning">incompatible</a>
  253   major version of that module unless such a version is requested explicitly
  254   or is already required.
  255   <code>go</code> <code>list</code> also omits incompatible major versions
  256   for such a module when fetching directly from version control, but may
  257   include them if reported by a proxy.
  258 </p>
  259 
  260 
  261 <h4 id="go.mod"><code>go.mod</code> file maintenance</h4>
  262 <!-- golang.org/issue/34822 -->
  263 
  264 <p>
  265   <code>go</code> commands other than
  266   <code>go</code> <code>mod</code> <code>tidy</code> no longer
  267   remove a <code>require</code> directive that specifies a version of an indirect dependency
  268   that is already implied by other (transitive) dependencies of the main
  269   module.
  270 </p>
  271 
  272 <p>
  273   <code>go</code> commands other than
  274   <code>go</code> <code>mod</code> <code>tidy</code> no longer
  275   edit the <code>go.mod</code> file if the changes are only cosmetic.
  276 </p>
  277 
  278 <p>
  279   When <code>-mod=readonly</code> is set, <code>go</code> commands will no
  280   longer fail due to a missing <code>go</code> directive or an erroneous
  281   <code>//&nbsp;indirect</code> comment.
  282 </p>
  283 
  284 <h4 id="module-downloading">Module downloading</h4>
  285 
  286 <p><!-- golang.org/issue/26092 -->
  287   The <code>go</code> command now supports Subversion repositories in module mode.
  288 </p>
  289 
  290 <p><!-- golang.org/issue/30748 -->
  291   The <code>go</code> command now includes snippets of plain-text error messages
  292   from module proxies and other HTTP servers.
  293   An error message will only be shown if it is valid UTF-8 and consists of only
  294   graphic characters and spaces.
  295 </p>
  296 
  297 <h4 id="go-test">Testing</h4>
  298 
  299 <p><!-- golang.org/issue/24929 -->
  300   <code>go test -v</code> now streams <code>t.Log</code> output as it happens,
  301   rather than at the end of all tests.
  302 </p>
  303 
  304 <h2 id="runtime">Runtime</h2>
  305 
  306 <p><!-- CL 190098 -->
  307   This release improves the performance of most uses
  308   of <code>defer</code> to incur almost zero overhead compared to
  309   calling the deferred function directly.
  310   As a result, <code>defer</code> can now be used in
  311   performance-critical code without overhead concerns.
  312 </p>
  313 
  314 <p><!-- CL 201760, CL 201762 and many others -->
  315   Goroutines are now asynchronously preemptible.
  316   As a result, loops without function calls no longer potentially
  317   deadlock the scheduler or significantly delay garbage collection.
  318   This is supported on all platforms except <code>windows/arm</code>,
  319   <code>darwin/arm</code>, <code>js/wasm</code>, and
  320   <code>plan9/*</code>.
  321 </p>
  322 
  323 <p>
  324   A consequence of the implementation of preemption is that on Unix
  325   systems, including Linux and macOS systems, programs built with Go
  326   1.14 will receive more signals than programs built with earlier
  327   releases.
  328   This means that programs that use packages
  329   like <a href="/pkg/syscall/"><code>syscall</code></a>
  330   or <a href="https://godoc.org/golang.org/x/sys/unix"><code>golang.org/x/sys/unix</code></a>
  331   will see more slow system calls fail with <code>EINTR</code> errors.
  332   Those programs will have to handle those errors in some way, most
  333   likely looping to try the system call again.  For more
  334   information about this
  335   see <a href="http://man7.org/linux/man-pages/man7/signal.7.html"><code>man
  336   7 signal</code></a> for Linux systems or similar documentation for
  337   other systems.
  338 </p>
  339 
  340 <p><!-- CL 201765, CL 195701 and many others -->
  341   The page allocator is more efficient and incurs significantly less
  342   lock contention at high values of <code>GOMAXPROCS</code>.
  343   This is most noticeable as lower latency and higher throughput for
  344   large allocations being done in parallel and at a high rate.
  345 </p>
  346 
  347 <p><!-- CL 171844 and many others -->
  348   Internal timers, used by
  349   <a href="/pkg/time/#After"><code>time.After</code></a>,
  350   <a href="/pkg/time/#Tick"><code>time.Tick</code></a>,
  351   <a href="/pkg/net/#Conn"><code>net.Conn.SetDeadline</code></a>,
  352   and friends, are more efficient, with less lock contention and fewer
  353   context switches.
  354   This is a performance improvement that should not cause any user
  355   visible changes.
  356 </p>
  357 
  358 <h2 id="compiler">Compiler</h2>
  359 
  360 <p><!-- CL 162237 -->
  361   This release adds <code>-d=checkptr</code> as a compile-time option
  362   for adding instrumentation to check that Go code is following
  363   <code>unsafe.Pointer</code> safety rules dynamically.
  364   This option is enabled by default (except on Windows) with
  365   the <code>-race</code> or <code>-msan</code> flags, and can be
  366   disabled with <code>-gcflags=all=-d=checkptr=0</code>.
  367   Specifically, <code>-d=checkptr</code> checks the following:
  368 </p>
  369 
  370 <ol>
  371   <li>
  372     When converting <code>unsafe.Pointer</code> to <code>*T</code>,
  373     the resulting pointer must be aligned appropriately
  374     for <code>T</code>.
  375   </li>
  376   <li>
  377     If the result of pointer arithmetic points into a Go heap object,
  378     one of the <code>unsafe.Pointer</code>-typed operands must point
  379     into the same object.
  380   </li>
  381 </ol>
  382 
  383 <p>
  384   Using <code>-d=checkptr</code> is not currently recommended on
  385   Windows because it causes false alerts in the standard library.
  386 </p>
  387 
  388 <p><!-- CL 204338 -->
  389   The compiler can now emit machine-readable logs of key optimizations
  390   using the <code>-json</code> flag, including inlining, escape
  391   analysis, bounds-check elimination, and nil-check elimination.
  392 </p>
  393 
  394 <p><!-- CL 196959 -->
  395   Detailed escape analysis diagnostics (<code>-m=2</code>) now work again.
  396   This had been dropped from the new escape analysis implementation in
  397   the previous release.
  398 </p>
  399 
  400 <p><!-- CL 196217 -->
  401   All Go symbols in macOS binaries now begin with an underscore,
  402   following platform conventions.
  403 </p>
  404 
  405 <p><!-- CL 202117 -->
  406   This release includes experimental support for compiler-inserted
  407   coverage instrumentation for fuzzing.
  408   See <a href="https://golang.org/issue/14565">issue 14565</a> for more
  409   details.
  410   This API may change in future releases.
  411 </p>
  412 
  413 <p><!-- CL 174704 --><!-- CL 196784 -->
  414   Bounds check elimination now uses information from slice creation and can
  415   eliminate checks for indexes with types smaller than <code>int</code>.
  416 </p>
  417 
  418 <h2 id="library">Core library</h2>
  419 
  420 <h3 id="hash/maphash">New byte sequence hashing package</h3>
  421 
  422 <p> <!-- golang.org/issue/28322, CL 186877 -->
  423   Go 1.14 includes a new package,
  424   <a href="/pkg/hash/maphash/"><code>hash/maphash</code></a>,
  425   which provides hash functions on byte sequences.
  426   These hash functions are intended to be used to implement hash tables or
  427   other data structures that need to map arbitrary strings or byte
  428   sequences to a uniform distribution on unsigned 64-bit integers.
  429 </p>
  430 <p>
  431   The hash functions are collision-resistant but not cryptographically secure.
  432 </p>
  433 <p>
  434   The hash value of a given byte sequence is consistent within a
  435   single process, but will be different in different processes.
  436 </p>
  437 
  438 <h3 id="minor_library_changes">Minor changes to the library</h3>
  439 
  440 <p>
  441   As always, there are various minor changes and updates to the library,
  442   made with the Go 1 <a href="/doc/go1compat">promise of compatibility</a>
  443   in mind.
  444 </p>
  445 
  446 <dl id="crypto/tls"><dt><a href="/pkg/crypto/tls/">crypto/tls</a></dt>
  447   <dd>
  448     <p><!-- CL 191976 -->
  449       Support for SSL version 3.0 (SSLv3) has been removed. Note that SSLv3 is the
  450       <a href="https://tools.ietf.org/html/rfc7568">cryptographically broken</a>
  451       protocol predating TLS.
  452     </p>
  453 
  454     <p><!-- CL 191999 -->
  455       TLS 1.3 can't be disabled via the <code>GODEBUG</code> environment
  456       variable anymore. Use the
  457       <a href="/pkg/crypto/tls/#Config.MaxVersion"><code>Config.MaxVersion</code></a>
  458       field to configure TLS versions.
  459     </p>
  460 
  461     <p><!-- CL 205059 -->
  462       When multiple certificate chains are provided through the
  463       <a href="/pkg/crypto/tls/#Config.Certificates"><code>Config.Certificates</code></a>
  464       field, the first one compatible with the peer is now automatically
  465       selected. This allows for example providing an ECDSA and an RSA
  466       certificate, and letting the package automatically select the best one.
  467       Note that the performance of this selection is going to be poor unless the
  468       <a href="/pkg/crypto/tls/#Certificate.Leaf"><code>Certificate.Leaf</code></a>
  469       field is set. The
  470       <a href="/pkg/crypto/tls/#Config.NameToCertificate"><code>Config.NameToCertificate</code></a>
  471       field, which only supports associating a single certificate with
  472       a give name, is now deprecated and should be left as <code>nil</code>.
  473       Similarly the
  474       <a href="/pkg/crypto/tls/#Config.BuildNameToCertificate"><code>Config.BuildNameToCertificate</code></a>
  475       method, which builds the <code>NameToCertificate</code> field
  476       from the leaf certificates, is now deprecated and should not be
  477       called.
  478     </p>
  479 
  480     <p><!-- CL 175517 -->
  481       The new <a href="/pkg/crypto/tls/#CipherSuites"><code>CipherSuites</code></a>
  482       and <a href="/pkg/crypto/tls/#InsecureCipherSuites"><code>InsecureCipherSuites</code></a>
  483       functions return a list of currently implemented cipher suites.
  484       The new <a href="/pkg/crypto/tls/#CipherSuiteName"><code>CipherSuiteName</code></a>
  485       function returns a name for a cipher suite ID.
  486     </p>
  487 
  488     <p><!-- CL 205058, 205057 -->
  489       The new <a href="/pkg/crypto/tls/#ClientHelloInfo.SupportsCertificate">
  490       <code>(*ClientHelloInfo).SupportsCertificate</code></a> and
  491       <a href="/pkg/crypto/tls/#CertificateRequestInfo.SupportsCertificate">
  492       <code>(*CertificateRequestInfo).SupportsCertificate</code></a>
  493       methods expose whether a peer supports a certain certificate.
  494     </p>
  495 
  496     <p><!-- CL 174329 -->
  497       The <code>tls</code> package no longer supports the legacy Next Protocol
  498       Negotiation (NPN) extension and now only supports ALPN. In previous
  499       releases it supported both. There are no API changes and applications
  500       should function identically as before. Most other clients and servers have
  501       already removed NPN support in favor of the standardized ALPN.
  502     </p>
  503 
  504     <p><!-- CL 205063, 205062 -->
  505       RSA-PSS signatures are now used when supported in TLS 1.2 handshakes. This
  506       won't affect most applications, but custom
  507       <a href="/pkg/crypto/tls/#Certificate.PrivateKey"><code>Certificate.PrivateKey</code></a>
  508       implementations that don't support RSA-PSS signatures will need to use the new
  509       <a href="/pkg/crypto/tls/#Certificate.SupportedSignatureAlgorithms">
  510       <code>Certificate.SupportedSignatureAlgorithms</code></a>
  511       field to disable them.
  512     </p>
  513 
  514     <p><!-- CL 205059, 205059 -->
  515       <a href="/pkg/crypto/tls/#Config.Certificates"><code>Config.Certificates</code></a> and
  516       <a href="/pkg/crypto/tls/#Config.GetCertificate"><code>Config.GetCertificate</code></a>
  517       can now both be nil if
  518       <a href="/pkg/crypto/tls/#Config.GetConfigForClient"><code>Config.GetConfigForClient</code></a>
  519       is set. If the callbacks return neither certificates nor an error, the
  520       <code>unrecognized_name</code> is now sent.
  521     </p>
  522 
  523     <p><!-- CL 205058 -->
  524       The new <a href="/pkg/crypto/tls/#CertificateRequestInfo.Version"><code>CertificateRequestInfo.Version</code></a>
  525       field provides the TLS version to client certificates callbacks.
  526     </p>
  527 
  528     <p><!-- CL 205068 -->
  529       The new <code>TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256</code> and
  530       <code>TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256</code> constants use
  531       the final names for the cipher suites previously referred to as
  532       <code>TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305</code> and
  533       <code>TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305</code>.
  534     </p>
  535   </dd>
  536 </dl><!-- crypto/tls -->
  537 
  538 <dl id="crypto/x509"><dt><a href="/pkg/crypto/x509/">crypto/x509</a></dt>
  539   <dd>
  540     <p><!-- CL 204046 -->
  541       <a href="/pkg/crypto/x509/#Certificate.CreateCRL"><code>Certificate.CreateCRL</code></a>
  542       now supports Ed25519 issuers.
  543     </p>
  544   </dd>
  545 </dl>
  546 
  547 <dl id="debug/dwarf"><dt><a href="/pkg/debug/dwarf/">debug/dwarf</a></dt>
  548   <dd>
  549     <p><!-- CL 175138 -->
  550       The <code>debug/dwarf</code> package now supports reading DWARF
  551       version 5.
  552     </p>
  553     <p>
  554       The new
  555       method <a href="/pkg/debug/dwarf/#Data.AddSection"><code>(*Data).AddSection</code></a>
  556       supports adding arbitrary new DWARF sections from the input file
  557       to the DWARF <code>Data</code>.
  558     </p>
  559 
  560     <p><!-- CL 192698 -->
  561       The new
  562       method <a href="/pkg/debug/dwarf/#Reader.ByteOrder"><code>(*Reader).ByteOrder</code></a>
  563       returns the byte order of the current compilation unit.
  564       This may be used to interpret attributes that are encoded in the
  565       native ordering, such as location descriptions.
  566     </p>
  567 
  568     <p><!-- CL 192699 -->
  569       The new
  570       method <a href="/pkg/debug/dwarf/#LineReader.Files"><code>(*LineReader).Files</code></a>
  571       returns the file name table from a line reader.
  572       This may be used to interpret the value of DWARF attributes such
  573       as <code>AttrDeclFile</code>.
  574     </p>
  575   </dd>
  576 </dl><!-- debug/dwarf -->
  577 
  578 <dl id="encoding/asn1"><dt><a href="/pkg/encoding/asn1/">encoding/asn1</a></dt>
  579   <dd>
  580     <p><!-- CL 126624 -->
  581       <a href="/pkg/encoding/asn1/#Unmarshal"><code>Unmarshal</code></a>
  582       now supports ASN.1 string type BMPString, represented by the new
  583       <a href="/pkg/encoding/asn1/#TagBMPString"><code>TagBMPString</code></a>
  584       constant.
  585     </p>
  586   </dd>
  587 </dl><!-- encoding/asn1 -->
  588 
  589 <dl id="encoding/json"><dt><a href="/pkg/encoding/json/">encoding/json</a></dt>
  590   <dd>
  591     <p><!-- CL 200677 -->
  592       The <a href="/pkg/encoding/json/#Decoder"><code>Decoder</code></a>
  593       type supports a new
  594       method <a href="/pkg/encoding/json/#Decoder.InputOffset"><code>InputOffset</code></a>
  595       that returns the input stream byte offset of the current
  596       decoder position.
  597     </p>
  598 
  599     <p><!-- CL 200217 -->
  600       <a href="/pkg/encoding/json/#Compact"><code>Compact</code></a> no longer
  601       escapes the <code>U+2028</code> and <code>U+2029</code> characters, which
  602       was never a documented feature. For proper escaping, see <a
  603       href="/pkg/encoding/json/#HTMLEscape"><code>HTMLEscape</code></a>.
  604     </p>
  605 
  606     <p><!-- CL 195045 -->
  607       <a href="/pkg/encoding/json/#Number"><code>Number</code></a> no longer
  608       accepts invalid numbers, to follow the documented behavior more closely.
  609       If a program needs to accept invalid numbers like the empty string,
  610       consider wrapping the type with <a href="/pkg/encoding/json/#Unmarshaler"><code>Unmarshaler</code></a>.
  611     </p>
  612 
  613     <p><!-- CL 200237 -->
  614       <a href="/pkg/encoding/json/#Unmarshal"><code>Unmarshal</code></a>
  615       can now support map keys with string underlying type which implement
  616       <a href="/pkg/encoding/#TextUnmarshaler"><code>encoding.TextUnmarshaler</code></a>.
  617     </p>
  618   </dd>
  619 </dl><!-- encoding/json -->
  620 
  621 <dl id="go/build"><dt><a href="/pkg/go/build/">go/build</a></dt>
  622   <dd>
  623     <p><!-- CL 203820, 211657 -->
  624       The <a href="/pkg/go/build/#Context"><code>Context</code></a>
  625       type has a new field <code>Dir</code> which may be used to set
  626       the working directory for the build.
  627       The default is the current directory of the running process.
  628       In module mode, this is used to locate the main module.
  629     </p>
  630   </dd>
  631 </dl><!-- go/build -->
  632 
  633 <dl id="go/doc"><dt><a href="/pkg/go/doc/">go/doc</a></dt>
  634   <dd>
  635     <p><!-- CL 204830 -->
  636       The new
  637       function <a href="/pkg/go/doc/#NewFromFiles"><code>NewFromFiles</code></a>
  638       computes package documentation from a list
  639       of <code>*ast.File</code>'s and associates examples with the
  640       appropriate package elements.
  641       The new information is available in a new <code>Examples</code>
  642       field
  643       in the <a href="/pkg/go/doc/#Package"><code>Package</code></a>, <a href="/pkg/go/doc/#Type"><code>Type</code></a>,
  644       and <a href="/pkg/go/doc/#Func"><code>Func</code></a> types, and a
  645       new <a href="/pkg/go/doc/#Example.Suffix"><code>Suffix</code></a>
  646       field in
  647       the <a href="/pkg/go/doc/#Example"><code>Example</code></a>
  648       type.
  649     </p>
  650   </dd>
  651 </dl><!-- go/doc -->
  652 
  653 <dl id="io/ioutil"><dt><a href="/pkg/io/ioutil/">io/ioutil</a></dt>
  654   <dd>
  655     <p><!-- CL 198488 -->
  656       <a href="/pkg/io/ioutil/#TempDir"><code>TempDir</code></a> can now create directories
  657       whose names have predictable prefixes and suffixes.
  658       As with <a href="/pkg/io/ioutil/#TempFile"><code>TempFile</code></a>, if the pattern
  659       contains a '*', the random string replaces the last '*'.
  660     </p>
  661   </dd>
  662 </dl>
  663 
  664 <dl id="log"><dt><a href="/pkg/log/">log</a></dt>
  665   <dd>
  666     <p><!-- CL 186182 -->
  667       The
  668       new <a href="https://tip.golang.org/pkg/log/#pkg-constants"><code>Lmsgprefix</code></a>
  669       flag may be used to tell the logging functions to emit the
  670       optional output prefix immediately before the log message rather
  671       than at the start of the line.
  672     </p>
  673   </dd>
  674 </dl><!-- log -->
  675 
  676 <dl id="math"><dt><a href="/pkg/math/">math</a></dt>
  677   <dd>
  678     <p><!-- CL 127458 -->
  679       The new <a href="/pkg/math/#FMA"><code>FMA</code></a> function
  680       computes <code>x*y+z</code> in floating point with no
  681       intermediate rounding of the <code>x*y</code>
  682       computation. Several architectures implement this computation
  683       using dedicated hardware instructions for additional performance.
  684     </p>
  685   </dd>
  686 </dl><!-- math -->
  687 
  688 <dl id="math/big"><dt><a href="/pkg/math/big/">math/big</a></dt>
  689   <dd>
  690     <p><!-- CL 164972 -->
  691       The <a href="/pkg/math/big/#Int.GCD"><code>GCD</code></a> method
  692       now allows the inputs <code>a</code> and <code>b</code> to be
  693       zero or negative.
  694     </p>
  695   </dd>
  696 </dl><!-- math/big -->
  697 
  698 <dl id="math/bits"><dt><a href="/pkg/math/bits/">math/bits</a></dt>
  699   <dd>
  700     <p><!-- CL 197838 -->
  701       The new functions
  702       <a href="/pkg/math/bits/#Rem"><code>Rem</code></a>,
  703       <a href="/pkg/math/bits/#Rem32"><code>Rem32</code></a>, and
  704       <a href="/pkg/math/bits/#Rem64"><code>Rem64</code></a>
  705       support computing a remainder even when the quotient overflows.
  706     </p>
  707   </dd>
  708 </dl><!-- math/bits -->
  709 
  710 <dl id="mime"><dt><a href="/pkg/mime/">mime</a></dt>
  711   <dd>
  712     <p><!-- CL 186927 -->
  713       The default type of <code>.js</code> and <code>.mjs</code> files
  714       is now <code>text/javascript</code> rather
  715       than <code>application/javascript</code>.
  716       This is in accordance
  717       with <a href="https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/">an
  718       IETF draft</a> that treats <code>application/javascript</code> as obsolete.
  719     </p>
  720   </dd>
  721 </dl><!-- mime -->
  722 
  723 <dl id="mime/multipart"><dt><a href="/pkg/mime/multipart/">mime/multipart</a></dt>
  724   <dd>
  725     <p>
  726       The
  727       new <a href="/pkg/mime/multipart/#Reader"><code>Reader</code></a>
  728       method <a href="/pkg/mime/multipart/#Reader.NextRawPart"><code>NextRawPart</code></a>
  729       supports fetching the next MIME part without transparently
  730       decoding <code>quoted-printable</code> data.
  731     </p>
  732   </dd>
  733 </dl><!-- mime/multipart -->
  734 
  735 <dl id="net/http"><dt><a href="/pkg/net/http/">net/http</a></dt>
  736   <dd>
  737     <p><!-- CL 200760 -->
  738       The new <a href="/pkg/net/http/#Header"><code>Header</code></a>
  739       method <a href="/pkg/net/http/#Header.Values"><code>Values</code></a>
  740       can be used to fetch all values associated with a
  741       canonicalized key.
  742     </p>
  743 
  744     <p><!-- CL 61291 -->
  745       The
  746       new <a href="/pkg/net/http/#Transport"><code>Transport</code></a>
  747       field <a href="/pkg/net/http/#Transport.DialTLSContext"><code>DialTLSContext</code></a>
  748       can be used to specify an optional dial function for creating
  749       TLS connections for non-proxied HTTPS requests.
  750       This new field can be used instead
  751       of <a href="/pkg/net/http/#Transport.DialTLS"><code>DialTLS</code></a>,
  752       which is now considered deprecated; <code>DialTLS</code> will
  753       continue to work, but new code should
  754       use <code>DialTLSContext</code>, which allows the transport to
  755       cancel dials as soon as they are no longer needed.
  756     </p>
  757 
  758     <p><!-- CL 192518, CL 194218 -->
  759       On Windows, <a href="/pkg/net/http/#ServeFile"><code>ServeFile</code></a> now correctly
  760       serves files larger than 2GB.
  761     </p>
  762   </dd>
  763 </dl><!-- net/http -->
  764 
  765 <dl id="net/http/httptest"><dt><a href="/pkg/net/http/httptest/">net/http/httptest</a></dt>
  766   <dd>
  767     <p><!-- CL 201557 -->
  768       The
  769       new <a href="/pkg/net/http/httptest/#Server"><code>Server</code></a>
  770       field <a href="/pkg/net/http/httptest/#Server.EnableHTTP2"><code>EnableHTTP2</code></a>
  771       supports enabling HTTP/2 on the test server.
  772     </p>
  773   </dd>
  774 </dl><!-- net/http/httptest -->
  775 
  776 <dl id="net/textproto"><dt><a href="/pkg/net/textproto/">net/textproto</a></dt>
  777   <dd>
  778     <p><!-- CL 200760 -->
  779       The
  780       new <a href="/pkg/net/textproto/#MIMEHeader"><code>MIMEHeader</code></a>
  781       method <a href="/pkg/net/textproto/#MIMEHeader.Values"><code>Values</code></a>
  782       can be used to fetch all values associated with a canonicalized
  783       key.
  784     </p>
  785   </dd>
  786 </dl><!-- net/textproto -->
  787 
  788 <dl id="net/url"><dt><a href="/pkg/net/url/">net/url</a></dt>
  789   <dd>
  790     <p><!-- CL 185117 -->
  791       When parsing of a URL fails
  792       (for example by <a href="/pkg/net/url/#Parse"><code>Parse</code></a>
  793       or <a href="/pkg/net/url/#ParseRequestURI"><code>ParseRequestURI</code></a>),
  794       the resulting <a href="/pkg/net/url/#Error.Error"><code>Error</code></a> message
  795       will now quote the unparsable URL.
  796       This provides clearer structure and consistency with other parsing errors.
  797     </p>
  798   </dd>
  799 </dl><!-- net/url -->
  800 
  801 <dl id="os/signal"><dt><a href="/pkg/os/signal/">os/signal</a></dt>
  802   <dd>
  803     <p><!-- CL 187739 -->
  804       On Windows,
  805       the <code>CTRL_CLOSE_EVENT</code>, <code>CTRL_LOGOFF_EVENT</code>,
  806       and <code>CTRL_SHUTDOWN_EVENT</code> events now generate
  807       a <code>syscall.SIGTERM</code> signal, similar to how Control-C
  808       and Control-Break generate a <code>syscall.SIGINT</code> signal.
  809     </p>
  810   </dd>
  811 </dl><!-- os/signal -->
  812 
  813 <dl id="plugin"><dt><a href="/pkg/plugin/">plugin</a></dt>
  814   <dd>
  815     <p><!-- CL 191617 -->
  816       The <code>plugin</code> package now supports <code>freebsd/amd64</code>.
  817     </p>
  818   </dd>
  819 </dl><!-- plugin -->
  820 
  821 <dl id="reflect"><dt><a href="/pkg/reflect/">reflect</a></dt>
  822   <dd>
  823     <p><!-- CL 85661 -->
  824       <a href="/pkg/reflect#StructOf"><code>StructOf</code></a> now
  825       supports creating struct types with unexported fields, by
  826       setting the <code>PkgPath</code> field in
  827       a <code>StructField</code> element.
  828     </p>
  829   </dd>
  830 </dl><!-- reflect -->
  831 
  832 <dl id="pkg-runtime"><dt><a href="/pkg/runtime/">runtime</a></dt>
  833   <dd>
  834     <p><!-- CL 200081 -->
  835       <code>runtime.Goexit</code> can no longer be aborted by a
  836       recursive <code>panic</code>/<code>recover</code>.
  837     </p>
  838 
  839     <p><!-- CL 188297, CL 191785 -->
  840       On macOS, <code>SIGPIPE</code> is no longer forwarded to signal
  841       handlers installed before the Go runtime is initialized.
  842       This is necessary because macOS delivers <code>SIGPIPE</code>
  843       <a href="https://golang.org/issue/33384">to the main thread</a>
  844       rather than the thread writing to the closed pipe.
  845     </p>
  846   </dd>
  847 </dl><!-- runtime -->
  848 
  849 <dl id="runtime/pprof"><dt><a href="/pkg/runtime/pprof/">runtime/pprof</a></dt>
  850   <dd>
  851     <p><!-- CL 204636, 205097 -->
  852     The generated profile no longer includes the pseudo-PCs used for inline
  853     marks. Symbol information of inlined functions is encoded in
  854     <a href="https://github.com/google/pprof/blob/5e96527/proto/profile.proto#L177-L184">the format</a>
  855     the pprof tool expects. This is a fix for the regression introduced
  856     during recent releases.
  857     </p>
  858   </dd>
  859 </dl><!-- runtime/pprof -->
  860 
  861 <dl id="strconv"><dt><a href="/pkg/strconv/">strconv</a></dt>
  862   <dd>
  863     <p>
  864       The <a href="/pkg/strconv/#NumError"><code>NumError</code></a>
  865       type now has
  866       an <a href="/pkg/strconv/#NumError.Unwrap"><code>Unwrap</code></a>
  867       method that may be used to retrieve the reason that a conversion
  868       failed.
  869       This supports using <code>NumError</code> values
  870       with <a href="/pkg/errors/#Is"><code>errors.Is</code></a> to see
  871       if the underlying error
  872       is <a href="/pkg/strconv/#pkg-variables"><code>strconv.ErrRange</code></a>
  873       or <a href="/pkg/strconv/#pkg-variables"><code>strconv.ErrSyntax</code></a>.
  874     </p>
  875   </dd>
  876 </dl><!-- strconv -->
  877 
  878 <dl id="sync"><dt><a href="/pkg/sync/">sync</a></dt>
  879   <dd>
  880     <p><!-- CL 200577 -->
  881       Unlocking a highly contended <code>Mutex</code> now directly
  882       yields the CPU to the next goroutine waiting for
  883       that <code>Mutex</code>. This significantly improves the
  884       performance of highly contended mutexes on high CPU count
  885       machines.
  886     </p>
  887   </dd>
  888 </dl><!-- sync -->
  889 
  890 <dl id="testing"><dt><a href="/pkg/testing/">testing</a></dt>
  891   <dd>
  892     <p><!-- CL 201359 -->
  893        The testing package now supports cleanup functions, called after
  894        a test or benchmark has finished, by calling
  895        <a href="/pkg/testing#T.Cleanup"><code>T.Cleanup</code></a> or
  896        <a href="/pkg/testing#B.Cleanup"><code>B.Cleanup</code></a> respectively.
  897     </p>
  898   </dd>
  899 </dl><!-- testing -->
  900 
  901 <dl id="text/template"><dt><a href="/pkg/text/template/">text/template</a></dt>
  902   <dd>
  903     <p><!-- CL 206124 -->
  904       The text/template package now correctly reports errors when a
  905       parenthesized argument is used as a function.
  906       This most commonly shows up in erroneous cases like
  907       <code>{{if (eq .F "a") or (eq .F "b")}}</code>.
  908       This should be written as <code>{{if or (eq .F "a") (eq .F "b")}}</code>.
  909       The erroneous case never worked as expected, and will now be
  910       reported with an error <code>can't give argument to non-function</code>.
  911     </p>
  912   </dd>
  913 </dl><!-- text/template -->
  914 
  915 <dl id="unicode"><dt><a href="/pkg/unicode/">unicode</a></dt>
  916   <dd>
  917     <p>
  918       The <a href="/pkg/unicode/"><code>unicode</code></a> package and associated
  919       support throughout the system has been upgraded from Unicode 11.0 to
  920       <a href="https://www.unicode.org/versions/Unicode12.0.0/">Unicode 12.0</a>,
  921       which adds 554 new characters, including four new scripts, and 61 new emoji.
  922     </p>
  923   </dd>
  924 </dl><!-- unicode -->