-
Notifications
You must be signed in to change notification settings - Fork 0
/
go1.5.html
1151 lines (975 loc) · 41.4 KB
/
go1.5.html
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
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!--{
"Title": "Go 1.5 Release Notes",
"Path": "/doc/go1.5",
"Template": true
}-->
<h2 id="introduction">Introduction to Go 1.5</h2>
<p>
The latest Go release, version 1.5,
is a significant release, including major architectural changes to the implementation.
Despite that, we expect almost all Go programs to continue to compile and run as before,
because the release still maintains the Go 1 <a href="/doc/go1compat.html">promise
of compatibility</a>.
</p>
<p>
The biggest developments in the implementation are:
</p>
<ul>
<li>
The compiler and runtime are now written entirely in Go (with a little assembler).
C is no longer involved in the implementation, and so the C compiler that was
once necessary for building the distribution is gone.
</li>
<li>
The garbage collector is now <a href="https://golang.org/s/go14gc">concurrent</a> and provides dramatically lower
pause times by running, when possible, in parallel with other goroutines.
</li>
<li>
By default, Go programs run with <code>GOMAXPROCS</code> set to the
number of cores available; in prior releases it defaulted to 1.
</li>
<li>
Support for <a href="http://golang.org/s/go14internal">internal packages</a>
is now provided for all repositories, not just the Go core.
</li>
<li>
The <code>go</code> command now provides <a href="https://golang.org/s/go15vendor">experimental
support</a> for "vendoring" external dependencies.
</li>
<li>
A new <code>go tool trace</code> command supports fine-grained
tracing of program execution.
</li>
<li>
A new <code>go doc</code> command (distinct from <code>godoc</code>)
is customized for command-line use.
</li>
</ul>
<p>
These and a number of other changes to the implementation and tools
are discussed below.
</p>
<p>
The release also contains one small language change involving map literals.
</p>
<p>
Finally, the timing of the <a href="https://golang.org/s/releasesched">release</a>
strays from the usual six-month interval,
both to provide more time to prepare this major release and to shift the schedule thereafter to
time the release dates more conveniently.
</p>
<h2 id="language">Changes to the language</h2>
<h3 id="map_literals">Map literals</h3>
<p>
Due to an oversight, the rule that allowed the element type to be elided from slice literals was not
applied to map keys.
This has been <a href="/cl/2591">corrected</a> in Go 1.5.
An example will make this clear: as of Go 1.5, this map literal,
</p>
<pre>
m := map[Point]string{
Point{29.935523, 52.891566}: "Persepolis",
Point{-25.352594, 131.034361}: "Uluru",
Point{37.422455, -122.084306}: "Googleplex",
}
</pre>
<p>
may be written as follows, without the <code>Point</code> type listed explicitly:
</p>
<pre>
m := map[Point]string{
{29.935523, 52.891566}: "Persepolis",
{-25.352594, 131.034361}: "Uluru",
{37.422455, -122.084306}: "Googleplex",
}
</pre>
<h2 id="implementation">The Implementation</h2>
<h3 id="c">No more C</h3>
<p>
The compiler and runtime are now implemented in Go and assembler, without C.
The only C source left in the tree is related to testing or to <code>cgo</code>.
There was a C compiler in the tree in 1.4 and earlier.
It was used to build the runtime; a custom compiler was necessary in part to
guarantee the C code would work with the stack management of goroutines.
Since the runtime is in Go now, there is no need for this C compiler and it is gone.
Details of the process to eliminate C are discussed <a href="https://golang.org/s/go13compiler">elsewhere</a>.
</p>
<p>
The conversion from C was done with the help of custom tools created for the job.
Most important, the compiler was actually moved by automatic translation of
the C code into Go.
It is in effect the same program in a different language.
It is not a new implementation
of the compiler so we expect the process will not have introduced new compiler
bugs.
An overview of this process is available in the slides for
<a href="https://talks.golang.org/2015/gogo.slide">this presentation</a>.
</p>
<h3 id="compiler_and_tools">Compiler and tools</h3>
<p>
Independent of but encouraged by the move to Go, the names of the tools have changed.
The old names <code>6g</code>, <code>8g</code> and so on are gone; instead there
is just one binary, accessible as <code>go</code> <code>tool</code> <code>compile</code>,
that compiles Go source into binaries suitable for the architecture and operating system
specified by <code>$GOARCH</code> and <code>$GOOS</code>.
Similarly, there is now one linker (<code>go</code> <code>tool</code> <code>link</code>)
and one assembler (<code>go</code> <code>tool</code> <code>asm</code>).
The linker was translated automatically from the old C implementation,
but the assembler is a new native Go implementation discussed
in more detail below.
</p>
<p>
Similar to the drop of the names <code>6g</code>, <code>8g</code>, and so on,
the output of the compiler and assembler are now given a plain <code>.o</code> suffix
rather than <code>.8</code>, <code>.6</code>, etc.
</p>
<h3 id="gc">Garbage collector</h3>
<p>
The garbage collector has been re-engineered for 1.5 as part of the development
outlined in the <a href="https://golang.org/s/go14gc">design document</a>.
Expected latencies are much lower than with the collector
in prior releases, through a combination of advanced algorithms,
better <a href="https://golang.org/s/go15gcpacing">scheduling</a> of the collector,
and running more of the collection in parallel with the user program.
The "stop the world" phase of the collector
will almost always be under 10 milliseconds and usually much less.
</p>
<p>
For systems that benefit from low latency, such as user-responsive web sites,
the drop in expected latency with the new collector may be important.
</p>
<p>
Details of the new collector were presented in TODO: GopherCon talk.
</p>
<h3 id="runtime">Runtime</h3>
<p>
In Go 1.5, the order in which goroutines are scheduled has been changed.
The properties of the scheduler were never defined by the language,
but programs that depended on the scheduling order may be broken
by this change.
We have seen a few (erroneous) programs affected by this change.
If you have programs that implicitly depend on the scheduling
order, you will need to update them.
</p>
<p>
Another potentially breaking change is that the runtime now
sets the default number of threads to run simultaneously,
defined by <code>GOMAXPROCS</code>, to the number
of cores available on the CPU.
In prior releases it defaulted to 1.
Programs that do not expect to run with multiple cores may
break inadvertently.
They can be updated by removing the restriction or by setting
<code>GOMAXPROCS</code> explicitly.
</p>
<h3 id="build">Build</h3>
<p>
Now that the Go compiler and runtime are implemented in Go, a Go compiler
must be available to compile the distribution from source.
Thus, to build the Go core, a working Go distribution must already be in place.
(Go programmers who do not work on the core are unaffected by this change.)
Any Go 1.4 or later distribution (including <code>gccgo</code>) will serve.
For details, see the <a href="https://golang.org/s/go15bootstrap">design document</a>.
</p>
<h2 id="ports">Ports</h2>
<p>
Due mostly to the industry's move away the 32-bit x86 architecture,
the set of binary downloads provided is reduced in 1.5.
A distribution for the OS X operating system is provided only for the
<code>amd64</code> architecture, not <code>386</code>.
Similarly, the ports for Snow Leopard (Apple OS X 10.6) still work but are no
longer released as a download or maintained since Apple no longer maintains that version
of the operating system.
Also, the <code>dragonfly/386</code> port is no longer supported at all
because DragonflyBSD itself no longer supports the 32-bit 386 architecture.
</p>
<p>
There are however several new ports available to be built from source.
These include <code>darwin/arm</code> and <code>darwin/arm64</code>.
The new port <code>linux/arm64</code> is mostly in place, but <code>cgo</code>
is only supported using external linking.
</p>
<p>
On FreeBSD, Go 1.5 requires FreeBSD 8-STABLE+ because of its new use of the <code>SYSCALL</code> instruction.
</p>
<p>
On NaCl, Go 1.5 requires SDK version pepper-39 or above because it now uses the
<code>get_random_bytes</code> system call.
</p>
<h2 id="tools">Tools</h2>
<h3 id="translate">Translating</h3>
<p>
As part of the process to eliminate C from the tree, the compiler and
linker were translated from C to Go.
It was a genuine (machine assisted) translation, so the new programs are essentially
the old programs translated rather than new ones with new bugs.
We are confident the translation process has introduced few if any new bugs,
and in fact uncovered a number of previously unknown bugs, now fixed.
</p>
<p>
The assembler is a new program, however; it is described below.
</p>
<h3 id="rename">Renaming</h3>
<p>
The suites of programs that were the compilers (<code>6g</code>, <code>8g</code>, etc.),
the assemblers (<code>6a</code>, <code>8a</code>, etc.),
and the linkers (<code>6l</code>, <code>8l</code>, etc.)
have each been consolidated into a single tool that is configured
by the environment variables <code>GOOS</code> and <code>GOARCH</code>.
The old names are gone; the new tools are available through the <code>go</code> <code>tool</code>
mechanism as <code>go tool compile</code>,
<code>go tool asm</code>,
<code>and go tool link</code>.
Also, the file suffixes <code>.6</code>, <code>.8</code> etc. for the
intermediate object files are also gone; now they are just plain <code>.o</code> files.
</p>
<p>
For example, to build and link a program on amd64 for Darwin
using the tools directly, rather than through <code>go build</code>,
one would run:
</p>
<pre>
$ export GOOS=darwin GOARCH=amd64
$ go tool compile program.go
$ go tool link program.o
</pre>
<h3 id="moving">Moving</h3>
<p>
Because the <a href="/pkg/go/types/"><code>go/types</code></a> package
has now moved into the main repository (see below),
the <a href="/cmd/vet"><code>vet</code></a> and
<a href="/cmd/cover"><code>cover</code></a>
tools have also been moved.
They are no longer maintained in the external <code>golang.org/x/tools</code> repository,
although (deprecated) source still resides there for compatibility with old releases.
</p>
<h3 id="compiler">Compiler</h3>
<p>
As described above, the compiler in Go 1.5 is a single Go program,
translated from the old C source, that replaces <code>6g</code>, <code>8g</code>,
and so on.
Its target is configured by the environment variables <code>GOOS</code> and <code>GOARCH</code>.
</p>
<p>
The 1.5 compiler is mostly equivalent to the old,
but some internal details have changed.
One significant change is that evaluation of constants now uses
the <a href="/pkg/math/big/"><code>math/big</code></a> package
rather than a custom (and less well tested) implementation of high precision
arithmetic.
We do not expect this to affect the results.
</p>
<p>
For the amd64 architecture only, the compiler has a new option, <code>-dynlink</code>,
that assists dynamic linking by supporting references to Go symbols
defined in external shared libraries.
</p>
<h3 id="assembler">Assembler</h3>
<p>
Like the compiler and linker, the assembler in Go 1.5 is a single program
that replaces the suite of assemblers (<code>6a</code>,
<code>8a</code>, etc.) and the environment variables
<code>GOARCH</code> and <code>GOOS</code>
configure the architecture and operating system.
Unlike the other programs, the assembler is a wholly new program
written in Go.
</p>
<p>
The new assembler is very nearly compatible with the previous
ones, but there are a few changes that may affect some
assembler source files.
See the updated <a href="/doc/asm">assembler guide</a>
for more specific information about these changes. In summary:
</p>
<p>
First, the expression evaluation used for constants is a little
different.
It now uses unsigned 64-bit arithmetic and the precedence
of operators (<code>+</code>, <code>-</code>, <code><<</code>, etc.)
comes from Go, not C.
We expect these changes to affect very few programs but
manual verification may be required.
</p>
<p>
Perhaps more important is that some discrepancies between the
architectures in how the PC and SP are handled have been
eliminated.
Sometimes these registers represented hardware
registers, and sometimes pseudo-registers.
As of Go 1.5, the names <code>PC</code> and <code>SP</code>
are always pseudo-registers.
To refer to the hardware register, use the alternate representation such
as <code>R13</code> for the stack pointer and
<code>R15</code> for the hardware program counter on x86.
(The names are different on other architectures.)
To help enforce this change, references to the
<code>SP</code> and <code>PC</code>
pseudo-registers now always require an identifier:
<code>f+4(SP)</code> not <code>4(SP)</code>;
it is a syntax error to omit the identifier.
Uses of <code>SP</code> (say) as a hardware register
tend to omit the name, and they will now be flagged by
the assembler.
</p>
<p>
One minor change is that some of the old assemblers
permitted the notation
</p>
<pre>
constant=value
</pre>
<p>
to define a named constant.
Since this is always possible to do with the traditional
C-like <code>#define</code> notation, which is still
supported (the assembler includes an implementation
of a simplified C preprocessor), the feature was removed.
</p>
<h3 id="link">Linker</h3>
<p>
The linker in Go 1.5 is now one Go program,
that replaces <code>6l</code>, <code>8l</code>, etc.
Its operating system and instruction set are specified
by the environment variables <code>GOOS</code> and <code>GOARCH</code>.
</p>
<p>
There are a couple of other changes.
The more significant is the addition of a <code>-buildmode</code> option that
expands the style of linking; it now supports
situations such as building shared libraries and allowing other languages
to call into Go libraries.
Some of these were outlined in a <a href="https://golang.org/s/execmodes">design document</a>.
For a list of the available build modes and their use, run
</p>
<pre>
$ go help buildmode
</pre>
<p>
Another minor change is that the linker no longer records build time stamps in
the header of Windows executables.
Also, although this may be fixed, Windows cgo executables are missing some
DWARF information.
</p>
<h3 id="go_command">Go command</h3>
<p>
The <a href="/cmd/go"><code>go</code></a> command's basic operation
is unchanged, but there are a number of changes worth noting.
</p>
<p>
The previous release introduced the idea of a directory internal to a package
being unimportable through the <code>go</code> command.
In 1.4, it was tested with the introduction of some internal elements
in the core repository.
As suggested in the <a href="https://golang.org/s/go14internal">design document</a>,
that change is now being made available to all repositories.
The rules are explained in the design document, but in summary any
package in or under a directory named <code>internal</code> may
be imported by packages rooted in the same subtree.
Existing packages with directory elements named <code>internal</code> may be
inadvertently broken by this change, which was why it was advertised
in the last release.
</p>
<p>
Another change in how packages are handled is the experimental
addition of support for "vendoring".
TODO: This is undocumented in the go command itself.
TODO: Preliminary design in https://golang.org/s/go15vendor should be updated.
</p>
<p>
There have also been several minor changes.
Read the <a href="/cmd/go">documentation</a> for full details.
</p>
<ul>
<li>
SWIG support has been updated such that
<code>.swig</code> and <code>.swigcxx</code>
now require SWIG 3.0.6 or later.
</li>
<li>
The <code>std</code> (standard library) wildcard package name
now excludes commands.
A new <code>cmd</code> wildcard covers the commands.
</li>
<li>
A new <code>-toolexec</code> flag for building
allows substitution of a different command to invoke
the compiler and so on.
This acts as a custom replacement for <code>go tool</code>.
</li>
<li>
The build subcommand has a <code>-buildmode</code> option tied to the linker,
as described above.
</li>
<li>
An <code>-asmflags</code> build option has been added to provide
flags to the assembler.
However,
the <code>-ccflags</code> build option has been dropped. TODO: why?
</li>
<li>
cmd/go, testing: add go test -count (https://golang.org/cl/10669)
</li>
<li>
The <code>generate</code> subcommand has a couple of new features.
The <code>-run</code> option specifies a regular expression to select which directives
to execute; this was proposed but never implemented in 1.4.
The executing pattern now has access to two new environment variables:
<code>$GOLINE</code> returns the source line number of the directive
and <code>$DOLLAR</code> expands to a dollar sign.
</li>
</ul>
<h3 id="vet_command">Go vet command</h3>
<p>
The <a href="/cmd/vet"><code>go tool vet</code></a> command now does
more thorough validation of struct tags.
</p>
<h3 id="trace_command">Trace command</h3>
<pre>
TODO
cmd/trace: new command to view traces (https://golang.org/cl/3601)
</pre>
<h3 id="doc_command">Go doc command</h3>
<p>
A few releases back, the <code>go doc</code>
command was deleted as being unnecessary.
One could always run "<code>godoc .</code>" instead.
The 1.5 release introduces a new <a href="/cmd/doc"><code>go doc</code></a>
command with a more convenient command-line interface than
<code>godoc</code>'s.
It is designed for command-line usage specifically, and provides a more
compact and focused presentation of the documentation for a package
or its elements, according to the invocation.
It also provides case-insensitive matching and
support for showing the documentation for unexported symbols.
For details run "<code>go help doc</code>".
</p>
<h3 id="cgo">Cgo</h3>
<p>
When parsing <code>#cgo</code> lines,
the invocation <code>${SRCDIR}</code> is now
expanded into the path to the source directory.
This allows options to be passed to the
compiler and linker that involve file paths relative to the
source code directory. Without the expansion the paths would be
invalid when the current working directory changes.
</p>
<p>
On Windows, cgo now uses external linking by default.
</p>
<h2 id="performance">Performance</h2>
<p>
As always, the changes are so general and varied that precise statements
about performance are difficult to make.
The changes are even broader ranging than usual in this release, which
includes a new garbage collector and a conversion of the runtime to Go.
Some programs may run faster, some slower.
On average the programs in the Go 1 benchmark suite run a few percent faster in Go 1.5
than they did in Go 1.4,
while as mentioned above the garbage collector's pauses are
dramatically shorter, and almost always under 10 milliseconds.
</p>
<p>
Builds in Go 1.5 will be slower by a factor of about two.
The automatic translation of the compiler and linker from C to Go resulted in
unidiomatic Go code that performs poorly compared to well-written Go.
Analysis tools and refactoring helped to improve the code, but much remains to be done.
Further profiling and optimization will continue in Go 1.6 and future releases.
For more details, see these <a href="https://talks.golang.org/2015/gogo.slide">slides</a>
and associated <a href="https://www.youtube.com/watch?v=cF1zJYkBW4A">video</a>.
</p>
<h2 id="library">Core library</h2>
<h3 id="flag">Flag</h3>
<p>
The flag package's
<a href="/pkg/flag/#PrintDefaults"><code>PrintDefaults</code></a>
function, and method on <a href="/pkg/flag/#FlagSet"><code>FlagSet</code></a>,
have been modified to create nicer usage messages.
The format has been changed to be more human-friendly and in the usage
messages a word quoted with `backquotes` is taken to be the name of the
flag's operand to display in the usage message.
For instance, a flag created with the invocation,
</p>
<pre>
cpuFlag = flag.Int("cpu", 1, "run `N` processes in parallel")
</pre>
<p>
will show the help message,
</p>
<pre>
-cpu N
run N processes in parallel (default 1)
</pre>
<p>
Also, the default is now listed only when it is not the zero value for the type.
</p>
<h3 id="math_big">Floats in math/big</h3>
<p>
The <a href="/pkg/math/big/"><code>math/big</code></a> package
has a new, fundamental data type,
<a href="/pkg/math/big/#Float"><code>Float</code></a>,
which implements arbitrary-precision floating-point numbers.
A <code>Float</code> value is represented by a boolean sign,
a variable-length mantissa, and a 32-bit fixed-size signed exponent.
The precision of a <code>Float</code> (the mantissa size in bits)
can be specified explicitly or is otherwise determined by the first
operation that creates the value.
Once created, the size of a <code>Float</code>'s mantissa may be modified with the
<a href="/pkg/math/big/#Float.SetPrec"><code>SetPrec</code></a> method.
<code>Floats</code> support the concept of infinities, such as are created by
overflow, but values that would lead to the equivalent of IEEE 754 NaNs
trigger a panic.
<code>Float</code> operations support all IEEE-754 rounding modes.
When the precision is set to 24 (53) bits,
operations that stay within the range of normalized <code>float32</code>
(<code>float64</code>)
values produce the same results as the corresponding IEEE-754
arithmetic on those values.
</p>
<h3 id="go_types">Go types</h3>
<p>
The <a href="/pkg/go/types/"><code>go/types</code></a> package
up to now has been maintained in the <code>golang.org/x</code>
repository; as of Go 1.5 it has been relocated to the main repository.
The code at the old location is now deprecated.
There is also a modest API change in the package, discussed below.
</p>
<p>
Associated with this move, the
<a href="/pkg/go/constant/"><code>go/constant</code></a>
package also moved to the main repository;
it was <code>golang.org/x/tools/exact</code> before.
The <a href="/pkg/go/importer/"><code>go/importer</code></a> package
also moved to the main repository,
as well as some tools described above.
</p>
<h3 id="net">Net</h3>
<p>
The DNS resolver in the net package has almost always used <code>cgo</code> to access
the system interface.
A change in Go 1.5 means that on most Unix systems DNS resolution
will no longer require <code>cgo</code>, which simplifies execution
on those platforms.
Now, if the system's networking configuration permits, the native Go resolver
will suffice.
The important effect of this change is that each DNS resolution occupies a goroutine
rather than a thread,
so a program with multiple outstanding DNS requests will consume fewer operating
system resources.
</p>
<p>
The decision of how to run the resolver applies at run time, not build time.
The <code>netgo</code> build tag that has been used to enforce the use
of the Go resolver is no longer necessary, although it still works.
</p>
<p>
This change applies to Unix systems only.
Windows, Mac OS X, and Plan 9 systems behave as before.
</p>
<h3 id="reflect">Reflect</h3>
<p>
The <a href="/pkg/reflect/"><code>reflect</code></a> package
has two new functions: <a href="/pkg/reflect/#ArrayOf"><code>ArrayOf</code></a>
and <a href="/pkg/reflect/#FuncOf"><code>FuncOf</code></a>.
These functions, analogous to the extant
<a href="/pkg/reflect/#SliceOf"><code>SliceOf</code></a> function,
create new types at runtime to describe arrays and functions.
</p>
<h3 id="hardening">Hardening</h3>
<p>
Several dozen bugs were found in the standard library
through randomized testing with the
<a href="https://github.com/dvyukov/go-fuzz"><code>go-fuzz</code></a> tool.
Bugs were fixed in the
<a href="/pkg/archive/tar/"><code>archive/tar</code></a>,
<a href="/pkg/archive/zip/"><code>archive/zip</code></a>,
<a href="/pkg/compress/flate/"><code>compress/flate</code></a>,
<a href="/pkg/encoding/gob/"><code>encoding/gob</code></a>,
<a href="/pkg/fmt/"><code>fmt</code></a>,
<a href="/pkg/html/template/"><code>html/template</code></a>,
<a href="/pkg/image/gif/"><code>image/gif</code></a>,
<a href="/pkg/image/jpeg/"><code>image/jpeg</code></a>,
<a href="/pkg/image/png/"><code>image/png</code></a>, and
<a href="/pkg/text/template/"><code>text/template</code></a>,
packages.
The fixes harden the implementation against incorrect and malicious inputs.
</p>
<h3 id="minor_library_changes">Minor changes to the library</h3>
<ul>
<li>
The <a href="/pkg/archive/zip/"><code>archive/zip</code></a> package's
<a href="/pkg/archive/zip/#Writer"><code>Writer</code></a> type now has a
<a href="/pkg/archive/zip/#Writer.SetOffset"><code>SetOffset</code></a>
method to specify the location within the output stream at which to write the archive.
</li>
<li>
The <a href="/pkg/bufio/#Reader"><code>Reader</code></a> in the
<a href="/pkg/bufio/"><code>bufio</code></a> package now has a
<a href="/pkg/bufio/#Reader.Discard"><code>Discard</code></a>
method to discard data from the input.
</li>
<li>
Also in the <a href="/pkg/bytes/"><code>bytes</code></a> package,
the <a href="/pkg/bytes/#Buffer"><code>Buffer</code></a> type
now has a <a href="/pkg/bytes/#Buffer.Cap"><code>Cap</code></a> method
that reports the number of bytes allocated within the buffer.
Similarly, both the <a href="/pkg/bytes/"><code>bytes</code></a>
and <a href="/pkg/strings/"><code>strings</code></a> packages,
the <a href="/pkg/bytes/#Reader"><code>Reader</code></a>
type now has a <a href="/pkg/bytes/#Reader.Size"><code>Size</code></a>
method that reports the original length of the underlying slice or string.
</li>
<li>
Both the <a href="/pkg/bytes/"><code>bytes</code></a> and
<a href="/pkg/strings/"><code>strings</code></a> packages
also now have a <a href="/pkg/bytes/#LastIndexByte"><code>LastIndexByte</code></a>
function that locates the rightmost byte with that value in the argument.
</li>
<li>
The <a href="/pkg/crypto/"><code>crypto</code></a> package
has a new interface, <a href="/pkg/crypto/#Decrypter"><code>Decrypter</code></a>,
that abstracts the behavior of a private key used in asymmetric decryption.
</li>
<li>
In the <a href="/pkg/crypto/cipher/"><code>crypto/cipher</code></a> package,
the documentation for the <a href="/pkg/crypto/cipher/#Stream"><code>Stream</code></a>
interface has been clarified regarding the behavior when the source and destination are
different lengths.
If the destination is shorter than the source, the method will panic.
This is not a change in the implementation, only the documentation.
</li>
<li>
Also in the <a href="/pkg/crypto/cipher/"><code>crypto/cipher</code></a> package,
there is now support for nonce lengths other than 96 bytes in AES's Galois/Counter mode (GCM),
which some protocols require.
</li>
<li>
In the <a href="/pkg/crypto/elliptic/"><code>crypto/elliptic</code></a> package,
there is now a <code>Name</code> field in the
<a href="/pkg/crypto/elliptic/#CurveParams"><code>CurveParams</code></a> struct,
and the curves implemented in the package have been given names.
These names provide a safer way to select a curve, as opposed to
selecting its bit size, for cryptographic systems that are curve-dependent.
</li>
<li>
Also in the <a href="/pkg/crypto/elliptic/"><code>crypto/elliptic</code></a> package,
the <a href="/pkg/crypto/elliptic/#Unmarshal"><code>Unmarshal</code></a> function
now verifies that the point is actually on the curve.
(If it is not, the function returns nils).
This change guards against certain attacks.
</li>
<li>
The <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package
now defaults to TLS 1.0.
The old default, SSLv3, is still available through <a href="/pkg/crypto/tls/#Config"><code>Config</code></a> if needed.
</li>
<li>
Also, the <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package
now supports Signed Certificate Timestamps (SCTs) as specified in RFC 6962.
The server serves them if they are listed in the
<a href="/pkg/crypto/tls/#Certificate"><code>Certificate</code></a> struct,
and the client requests them and exposes them, if present,
in its <a href="/pkg/crypto/tls/#ConnectionState"><code>ConnectionState</code></a> struct.
The <a href="/pkg/crytpo/tls/"><code>crytpo/tls</code></a> server implementation
will also now always call the
<code>GetCertificate</code> function in
the <a href="/pkg/crypto/tls/#Config"><code>Config</code></a> struct
to select a certificate for the connection when none is supplied.
</li>
<li>
Finally, the session ticket keys in the
<a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package
can now be rotated (changed periodically during an active connection).
This is done through the new
<a href="/pkg/crypto/tls/#Config.SetSessionTicketKeys"><code>SetSessionTicketKeys</code></a>
method of the
<a href="/pkg/crypto/tls/#Config"><code>Config</code></a> type.
</li>
<li>
In the <a href="/pkg/crypto/x509/"><code>crypto/x509</code></a> package,
wildcards are now accepted only in the leftmost label as defined in
<a href="https://tools.ietf.org/html/rfc6125#section-6.4.3">the specification</a>.
</li>
<li>
Also in the <a href="/pkg/crypto/x509/"><code>crypto/x509</code></a> package,
the handling of unknown critical extensions has been changed.
They used to cause parse errors but now they are parsed and caused errors only
in <a href="/pkg/crypto/x509/#Certificate.Verify"><code>Verify</code></a>.
The new field <code>UnhandledCriticalExtensions</code> of
<a href="/pkg/crypto/x509/#Certificate"><code>Certificate</code></a> records these extensions.
</li>
<li>
The <a href="/pkg/database/sql/#DB"><code>DB</code></a> type of the
<a href="/pkg/database/sql/"><code>database/sql</code></a> package
now has a <a href="/pkg/database/sql/#DB.Stats"><code>Stats</code></a> method
to retrieve database statistics.
</li>
<li>
The <a href="/pkg/debug/dwarf/"><code>debug/dwarf</code></a>
package has extensive additions to better support DWARF version 4.
See for example the definition of the new type
<a href="/pkg/debug/dwarf/#Class"><code>Class</code></a>.
</li>
<li>
The <a href="/pkg/debug/elf/"><code>debug/elf</code></a>
package now has support for the 64-bit Power architecture.
</li>
<li>
The <a href="/pkg/encoding/base64/"><code>encoding/base64</code></a> package
now supports unpadded encodings through two new encoding variables,
<a href="/pkg/encoding/base64/#RawStdEncoding"><code>RawStdEncoding</code></a> and
<a href="/pkg/encoding/base64/#RawURLEncoding"><code>RawURLEncoding</code></a>.
</li>
<li>
The <a href="/pkg/encoding/json/"><code>encoding/json</code></a> package
now returns an <a href="/pkg/encoding/json/#UnmarshalTypeError"><code>UnmarshalTypeError</code></a>
if a JSON value is not appropriate for the target variable or component
to which it is being unmarshaled.
</li>
<li>
The <a href="/pkg/flag/"><code>flag</code></a> package
has a new function, <a href="/pkg/flag/#UnquoteUsage"><code>UnquoteUsage</code></a>,
to assist in the creation of usage messages using the new convention
described above.
</li>
<li>
Also in the <a href="/pkg/fmt/"><code>fmt</code></a> package,
a value of type <a href="/pkg/reflect/#Value"><code>Value</code></a> now
prints what it holds, rather than use the <code>reflect.Value</code>'s <code>Stringer</code>
method, which produces things like <code><int Value></code>.
</li>
<li>
The <a href="/pkg/ast/#EmptyStmt"><code>EmptyStmt</code></a> type
in the <a href="/pkg/go/ast/"><code>go/ast</code></a> package now
has a boolean <code>Implicit</code> field that records whether the
semicolon was implicitly added or was present in the source.
</li>
<li>
For forward compatibility the <a href="/pkg/go/build/"><code>go/build</code></a> package
reserves <code>GOARCH</code> values for a number of architectures that Go might support one day.
This is not a promise that it will.
Also, the <a href="/pkg/go/build/#Package"><code>Package</code></a> struct
now has a <code>PkgTargetRoot</code> field that stores the
architecture-dependent root directory in which to install, if known.
</li>
<li>
The (newly migrated) <a href="/pkg/go/types/"><code>go/types</code></a>
package allows one to control the prefix attached to package-level names using
the new <a href="/pkg/go/types/#Qualifier"><code>Qualifier</code></a>
function type as an argument to several functions. This is an API change for
the package, but since it is new to the core, it is not breaking the Go 1 compatibility
rules since code that uses the package must explicitly ask for it at its new location.
TODO: There should be a gofix for this.
</li>
<li>
In the <a href="/pkg/image/"><code>image</code></a> package,
the <a href="/pkg/image/#Rectangle"><code>Rectangle</code></a> type
now implements the <a href="/pkg/image/#Image"><code>Image</code></a> interface,
mask image when drawing.
</li>
<li>
Also in the <a href="/pkg/image/"><code>image</code></a> package,
to assist in the handling of some JPEG images,
there is now support for 4:1:1 and 4:1:0 YCbCr subsampling and basic
CMYK support, represented by the new image.CMYK struct.
</li>
<li>
The <a href="/pkg/image/color/"><code>image/color</code></a> package
adds basic CMYK support, through the new
<a href="/pkg/image/color/#CMYK"><code>CMYK</code></a> struct,
the <a href="/pkg/image/color/#CMYKModel"><code>CMYKModel</code></a> color model, and the
<a href="/pkg/image/color/#CMYKToRGB"><code>CMYKToRGB</code></a> function, as
needed by some JPEG images.
</li>
<li>
The <a href="/pkg/image/gif/"><code>image/gif</code></a> package
includes a couple of generalizations.
A multiple-frame GIF file can now have an overall bounds different
from all the contained single frames' bounds.
Also, the <a href="/pkg/image/gif/#GIF"><code>GIF</code></a> struct
now has a <code>Disposal</code> field
that specifies the disposal method for each frame.
</li>
<li>
The <a href="/pkg/io/"><code>io</code></a> package
adds a <a href="/pkg/io/#CopyBuffer"><code>CopyBuffer</code></a> function
that is like <a href="/pkg/io/#Copy"><code>Copy</code></a> but
uses a caller-provided buffer, permitting control of allocation and buffer size.
</li>
<li>
The <a href="/pkg/log/"><code>log</code></a> package
has a new <a href="/pkg/log/#LUTC"><code>LUTC</code></a> flag
that causes time stamps to be printed in the UTC time zone.
It also adds a <a href="/pkg/log/#SetOutput"><code>SetOutput</code></a> function
to set the output destination for the standard logger
and a corresponding method for user-created loggers.
</li>
<li>
In Go 1.4, <a href="/pkg/math/#Max"><code>Max</code></a> was not detecting all possible NaN bit patterns.
This is fixed in Go 1.5, so programs that use <code>math.Max</code> on data including NaNs may behave differently,
but now correctly according to the IEEE754 definition of NaNs.
</li>
<li>
The <a href="/pkg/math/big/"><code>math/big</code></a> package
adds a new <a href="/pkg/math/big/#Jacobi"><code>Jacobi</code></a>
function for integers and a new method
<a href="/pkg/math/big/#Int.ModSqrt"><code>ModSqrt</code></a>
method for the <a href="/pkg/math/big/#Int"><code>Int</code></a> type.
</li>
<li>
The mime package
adds a new <a href="/pkg/mime/#WordDecoder"><code>WordDecoder</code></a> type
to decode MIME headers containing RFC 204-encoded words.
It also provides <a href="/pkg/mime/#BEncoding"><code>BEncoding</code></a> and
<a href="/pkg/mime/#QEncoding"><code>QEncoding</code></a>
as implementations of the encoding schemes of RFC 2045 and RFC 2047.
</li>
<li>
The <a href="/pkg/mime/"><code>mime</code></a> package also adds an
<a href="/pkg/mime/#ExtensionsByType"><code>ExtensionsByType</code></a>
function that returns the MIME extensions know to be associated with a given MIME type.
</li>
<li>
There is a new <a href="/pkg/mime/quotedprintable/"><code>mime/quotedprintable</code></a>
package that implements the quoted-printable encoding defined by RFC 2045.
</li>
<li>
Go 1.5's <a href="/pkg/net/"><code>net</code></a> package
adds RFC-6555-compliant dialing for sites with multiple TCP
addresses listed in DNS.
A new <code>DualStack</code> field
in <a href="/pkg/net/#Dialer"><code>Dialer</code></a> enables the feature.
</li>
<li>
A number of inconsistencies in the types returned by errors in the