aboutsummaryrefslogtreecommitdiff
path: root/doc/go1.16.html
blob: 2ecf7db7c779ef7cbb5715d017caa02bcaf55ea7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
<!--{
	"Title": "Go 1.16 Release Notes",
	"Path":  "/doc/go1.16"
}-->

<!--
NOTE: In this document and others in this directory, the convention is to
set fixed-width phrases with non-fixed-width spaces, as in
<code>hello</code> <code>world</code>.
Do not send CLs removing the interior tags from such phrases.
-->

<style>
  main ul li { margin: 0.5em 0; }
</style>

<h2 id="introduction">DRAFT RELEASE NOTES — Introduction to Go 1.16</h2>

<p>
  <strong>
    Go 1.16 is not yet released. These are work-in-progress
    release notes. Go 1.16 is expected to be released in February 2021.
  </strong>
</p>

<h2 id="language">Changes to the language</h2>

<p>
  TODO
</p>

<h2 id="ports">Ports</h2>

<p>
  TODO
</p>

<h2 id="tools">Tools</h2>

<p>
  TODO
</p>

<h3 id="go-command">Go command</h3>

<h4 id="modules">Modules</h4>

<p><!-- golang.org/issue/40276 -->
  <code>go</code> <code>install</code> now accepts arguments with
  version suffixes (for example, <code>go</code> <code>install</code>
  <code>example.com/cmd@v1.0.0</code>). This causes <code>go</code>
  <code>install</code> to build and install packages in module-aware mode,
  ignoring the <code>go.mod</code> file in the current directory or any parent
  directory, if there is one. This is useful for installing executables without
  affecting the dependencies of the main module.<br>
  TODO: write and link to section in golang.org/ref/mod<br>
  TODO: write and link to blog post
</p>

<p><!-- golang.org/issue/24031 -->
  <code>retract</code> directives may now be used in a <code>go.mod</code> file
  to indicate that certain published versions of the module should not be used
  by other modules. A module author may retract a version after a severe problem
  is discovered or if the version was published unintentionally.<br>
  TODO: write and link to section in golang.org/ref/mod<br>
  TODO: write and link to tutorial or blog post
</p>

<p><!-- golang.org/issue/26603 -->
  The <code>go</code> <code>mod</code> <code>vendor</code>
  and <code>go</code> <code>mod</code> <code>tidy</code> subcommands now accept
  the <code>-e</code> flag, which instructs them to proceed despite errors in
  resolving missing packages.
</p>

<h4 id="go-test"><code>go</code> <code>test</code></h4>

<p><!-- golang.org/issue/29062 -->
  When using <code>go</code> <code>test</code>, a test that
  calls <code>os.Exit(0)</code> during execution of a test function
  will now be considered to fail.
  This will help catch cases in which a test calls code that calls
  <code>os.Exit(0)</code> and thereby stops running all future tests.
  If a <code>TestMain</code> function calls <code>os.Exit(0)</code>
  that is still considered to be a passing test.
</p>

<p><!-- golang.org/issue/37519 -->
  The <code>go</code> <code>get</code> <code>-insecure</code> flag is
  deprecated and will be removed in a future version. The <code>GOINSECURE</code>
  environment variable should be used instead, since it provides control
  over which modules may be retrieved using an insecure scheme. Unlike the
  <code>-insecure</code> flag, <code>GOINSECURE</code> does not disable module
  sum validation using the checksum database. The <code>GOPRIVATE</code> or
  <code>GONOSUMDB</code> environment variables may be used instead.
</p>

<h4 id="all-pattern">The <code>all</code> pattern</h4>

<p><!-- golang.org/cl/240623 -->
  When the main module's <code>go.mod</code> file
  declares <code>go</code> <code>1.16</code> or higher, the <code>all</code>
  package pattern now matches only those packages that are transitively imported
  by a package or test found in the main module. (Packages imported by <em>tests
  of</em> packages imported by the main module are no longer included.) This is
  the same set of packages retained
  by <code>go</code> <code>mod</code> <code>vendor</code> since Go 1.11.
</p>

<h3 id="cgo">Cgo</h3>

<p> <!-- CL 252378 -->
  The <a href="/cmd/cgo">cgo</a> tool will no longer try to translate
  C struct bitfields into Go struct fields, even if their size can be
  represented in Go. The order in which C bitfields appear in memory
  is implementation dependent, so in some cases the cgo tool produced
  results that were silently incorrect.
</p>

<p>
  TODO
</p>

<h2 id="runtime">Runtime</h2>

<p>
  TODO
</p>

<h2 id="compiler">Compiler</h2>

<p>
  TODO
</p>

<h2 id="linker">Linker</h2>

<p>
  This release includes additional improvements to the Go linker,
  reducing linker resource usage (both time and memory) and improving
  code robustness/maintainability. These changes form the second half
  of a two-release project to
  <a href="https://golang.org/s/better-linker">modernize the Go
  linker</a>.
</p>

<p>
  The linker changes in 1.16 extend the 1.15 improvements to all
  supported architecture/OS combinations (the 1.15 performance improvements
  were primarily focused on <code>ELF</code>-based OSes and
  <code>amd64</code> architectures).  For a representative set of
  large Go programs, linking is 20-35% faster than 1.15 and requires
  5-15% less memory on average for <code>linux/amd64</code>, with larger
  improvements for other architectures and OSes.
</p>

<p>
  TODO: update with final numbers later in the release.
</p>

<h2 id="library">Core library</h2>

<p>
  TODO
</p>

<h3 id="ctypto/tls"><a href="/pkg/crypto/tls">crypto/tls</a></h3>

<p><!-- CL 256897 -->
  I/O operations on closing or closed TLS connections can now be detected using
  the new <a href="/pkg/net/#ErrClosed">ErrClosed</a> error.  A typical use
  would be <code>errors.Is(err, net.ErrClosed)</code>.  In earlier releases
  the only way to reliably detect this case was to match the string returned
  by the <code>Error</code> method with <code>"tls: use of closed connection"</code>.
</p>

<h3 id="crypto/x509"><a href="/pkg/crypto/x509">crypto/x509</a></h3>

<p><!-- CL 235078 -->
  <a href="/pkg/crypto/x509/#ParseCertificate">ParseCertificate</a> and
  <a href="/pkg/crypto/x509/#CreateCertificate">CreateCertificate</a> both
  now enforce string encoding restrictions for the fields <code>DNSNames</code>,
  <code>EmailAddresses</code>, and <code>URIs</code>. These fields can only
  contain strings with characters within the ASCII range.
</p>

<h3 id="net"><a href="/pkg/net/">net</a></h3>

<p><!-- CL 250357 -->
  The case of I/O on a closed network connection, or I/O on a network
  connection that is closed before any of the I/O completes, can now
  be detected using the new <a href="/pkg/net/#ErrClosed">ErrClosed</a> error.
  A typical use would be <code>errors.Is(err, net.ErrClosed)</code>.
  In earlier releases the only way to reliably detect this case was to
  match the string returned by the <code>Error</code> method
  with <code>"use of closed network connection"</code>.
</p>


<h3 id="text/template/parse"><a href="/pkg/text/template/parse/">text/template/parse</a></h3>

<p><!-- CL 229398, golang.org/issue/34652 -->
  A new <a href="/pkg/text/template/parse/#CommentNode"><code>CommentNode</code></a>
  was added to the parse tree. The <a href="/pkg/text/template/parse/#Mode"><code>Mode</code></a>
  field in the <code>parse.Tree</code> enables access to it.
</p>
<!-- text/template/parse -->

<h3 id="unicode"><a href="/pkg/unicode/">unicode</a></h3>

<p><!-- CL 248765 -->
  The <a href="/pkg/unicode/"><code>unicode</code></a> package and associated
  support throughout the system has been upgraded from Unicode 12.0.0 to
  <a href="https://www.unicode.org/versions/Unicode13.0.0/">Unicode 13.0.0</a>,
  which adds 5,930 new characters, including four new scripts, and 55 new emoji.
  Unicode 13.0.0 also designates plane 3 (U+30000-U+3FFFF) as the tertiary
  ideographic plane.
</p>

<h3 id="minor_library_changes">Minor changes to the library</h3>

<p>
  As always, there are various minor changes and updates to the library,
  made with the Go 1 <a href="/doc/go1compat">promise of compatibility</a>
  in mind.
</p>

<p>
  TODO
</p>

<dl id="net/http"><dt><a href="/pkg/net/http/">net/http</a></dt>
  <dd>
    <p><!-- CL 233637 -->
      In the <a href="/pkg/net/http/"><code>net/http</code></a> package, the
      behavior of <a href="/pkg/net/http/#StripPrefix"><code>StripPrefix</code></a>
      has been changed to strip the prefix from the request URL's
      <code>RawPath</code> field in addition to its <code>Path</code> field.
      In past releases, only the <code>Path</code> field was trimmed, and so if the
      request URL contained any escaped characters the URL would be modified to
      have mismatched <code>Path</code> and <code>RawPath</code> fields.
      In Go 1.16, <code>StripPrefix</code> trims both fields.
      If there are escaped characters in the prefix part of the request URL the
      handler serves a 404 instead of its previous behavior of invoking the
      underlying handler with a mismatched <code>Path</code>/<code>RawPath</code> pair.
    </p>

    <p><!-- CL 252497 -->
     The <a href="/pkg/net/http/"><code>net/http</code></a> package now rejects HTTP range requests
     of the form <code>"Range": "bytes=--N"</code> where <code>"-N"</code> is a negative suffix length, for
     example <code>"Range": "bytes=--2"</code>. It now replies with a <code>416 "Range Not Satisfiable"</code> response.
    </p>
  </dd>
</dl><!-- net/http -->