Fixes a situation where a nested bad type would still
permit the outer type to install a working engine, leading
to inconsistent behavior.
Fixes#3273.
R=bsiegert, rsc
CC=golang-dev
https://golang.org/cl/6294067
A comment map associates comments with AST nodes
and permits correct updating of the AST's comment
list when the AST is manipulated.
R=rsc
CC=golang-dev
https://golang.org/cl/6281044
Patching the buffer with the output from gofmt -d only works if
the file already exists. If it doesn't, replace the content with
the output of gofmt.
R=sameer
CC=golang-dev
https://golang.org/cl/6302063
This slipped in with the implementation of Getpid in CL 5909043.
I'd exclude that CL entirely but it is tangled up in the Win32finddata changes.
R=golang-dev, minux.ma
CC=golang-dev
https://golang.org/cl/6297065
Preserve old API by using correct struct in system call
and then copying the results, as we did for SetsockoptLinger.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6307065
This new error is the only API change in the current draft of
Go 1.0.2 CLs. I'd like to include the CL that introduced it,
because it replaces a mysterious 'internal error' with a
useful error message, but I don't want any API changes,
so unexport the error constant for now. It can be
re-exported for Go 1.1.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/6294055
Fixes#3708.
The fix to allow 5{c,g,l} to compile under clang 3.1 broke cross
compilation on darwin using the Apple default compiler on 10.7.3.
This failure was introduced in 9b455eb64690.
This has been tested by cross compiling on darwin/amd64 to linux/arm using
* gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
* clang version 3.1 (branches/release_31)
As well as on linux/arm using
* gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
* Ubuntu clang version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0)
* Debian clang version 3.1-4 (branches/release_31) (based on LLVM 3.1)
R=consalus, rsc
CC=golang-dev
https://golang.org/cl/6307058
-lm must come after the source file, versions of gcc insist this strict order.
On standard compliant systems, we no longer need malloc.h for malloc.
Use pkg-config(1) to get correct glib cflags and libs.
Fix compiler warning in threadring.c and k-nucleotide.c.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6198076
The type declarations were being generated using
a range over a map, which meant that successive
runs produced different orders. This will make sure
successive runs produce the same files.
Fixes#3707.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6300062
If there are mutually recursive functions, there is a cycle in
the dependency graph, so the order is actually dependency order
among the strongly connected components: mutually recursive
functions get put into the same batch and analyzed together.
(Until now the entire package was put in one batch.)
The non-recursive case (single function, maybe with some
closures inside) will be able to be more precise about inputs
that escape only back to outputs, but that is not implemented yet.
R=ken2
CC=golang-dev, lvd
https://golang.org/cl/6304050
CL 4313064 fixed its test case but did not address a
general enough problem:
type T1 struct { F *T2 }
type T2 T1
type T3 T2
could still end up copying the definition of T1 for T2
before T1 was done being evaluated, or T3 before T2
was done.
In order to propagate the updates correctly,
record a copy of an incomplete type for re-execution
once the type is completed. Roll back CL 4313064.
Fixes#3709.
R=ken2
CC=golang-dev, lstoakes
https://golang.org/cl/6301059
This is part 1 of a 2 part changelist. Part 2 contains the mechanical
change to parse.go to compare atoms (ints) instead of strings.
The overall effect of the two changes are:
benchmark old ns/op new ns/op delta
BenchmarkParser 4462274 4058254 -9.05%
BenchmarkRawLevelTokenizer 913202 912917 -0.03%
BenchmarkLowLevelTokenizer 1268626 1267836 -0.06%
BenchmarkHighLevelTokenizer 1947305 1968944 +1.11%
R=rsc
CC=andybalholm, golang-dev, r
https://golang.org/cl/6305053
As discussed in
https://groups.google.com/d/msg/golang-dev/Na9XE6mcQyY/zbeBI7R-vnoJ
Here is a static copy of the go/parser benchmark. I ended up using
fancy encodings because the original parser.go had a number of `s
scattered throughout which made it hard to embed the source directly.
Curiously on my laptop this benchmark always scores roughly 10% higher
than the standalone benchmark. This may be down to the generation of
the fasta data set triggering the cpu governor to raise the cpu speed.
However the benchmark is consistent with itself across multiple runs.
R=golang-dev, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/6305055
