This is the result of running `gofix -r hashsum` over the tree, changing
the hash function implementations by hand and then fixing a couple of
instances where gofix didn't catch something.
The changed implementations are as simple as possible while still
working: I'm not trying to optimise in this CL.
R=rsc, cw, rogpeppe
CC=golang-dev
https://golang.org/cl/5448065
The wrong value made Nconv() show "1" for node "-1", and "2" from
node "2+3".
Fixes#2452.
R=gri, lvd, rsc
CC=golang-dev, remy
https://golang.org/cl/5435064
The allowed conversions before and after are:
type Tstring string
type Tbyte []byte
type Trune []rune
string <-> string // ok
string <-> []byte // ok
string <-> []rune // ok
string <-> Tstring // ok
string <-> Tbyte // was illegal, now ok
string <-> Trune // was illegal, now ok
Tstring <-> string // ok
Tstring <-> []byte // ok
Tstring <-> []rune // ok
Tstring <-> Tstring // ok
Tstring <-> Tbyte // was illegal, now ok
Tstring <-> Trune // was illegal, now ok
Update spec, compiler, tests. Use in a few packages.
We agreed on this a few months ago but never implemented it.
Fixes#1707.
R=golang-dev, gri, r
CC=golang-dev
https://golang.org/cl/5421057
An experiment: allow structs to be copied even if they
contain unexported fields. This gives packages the
ability to return opaque values in their APIs, like reflect
does for reflect.Value but without the kludgy hacks reflect
resorts to.
In general, we trust programmers not to do silly things
like *x = *y on a package's struct pointers, just as we trust
programmers not to do unicode.Letter = unicode.Digit,
but packages that want a harder guarantee can introduce
an extra level of indirection, like in the changes to os.File
in this CL or by using an interface type.
All in one CL so that it can be rolled back more easily if
we decide this is a bad idea.
Originally discussed in March 2011.
https://groups.google.com/group/golang-dev/t/3f5d30938c7c45ef
R=golang-dev, adg, dvyukov, r, bradfitz, jan.mercl, gri
CC=golang-dev
https://golang.org/cl/5372095
Allow any type in switch on interface value.
Statically check typeswitch early.
Fixes#2423.
Fixes#2424.
R=rsc, dsymonds
CC=golang-dev
https://golang.org/cl/5339045
This contains the files that required handiwork, mostly
Makefiles with updated TARGs, plus the two packages
with modified package names.
html/template/doc.go needs a separate edit pass.
test/fixedbugs/bug358.go is not legal go so gofix fails on it.
R=rsc
CC=golang-dev
https://golang.org/cl/5340050
Fixes#2355.
I have a test, but not sure if it's worth adding. Instead i've made
the patching-over in reflect.c methods more fatal and more descriptive.
R=rsc
CC=golang-dev
https://golang.org/cl/5302082
mark OADDR inserted by typecheck as implicit
OCOPY takes ->left and ->right, not ->list
OMAKE*'s can all have arguments
precedence for OIND was initalized twice
fixes#2414
R=rsc, dave
CC=golang-dev
https://golang.org/cl/5319065
Got rid of all the magic mystery globals. Now
for %N, %T, and %S, the flags +,- and # set a sticky
debug, sym and export mode, only visible in the new fmt.c.
Default is error mode. Handle h and l flags consistently with
the least side effects, so we can now change
things without worrying about unrelated things
breaking.
fixes#2361
R=rsc
CC=golang-dev
https://golang.org/cl/5316043
There is no semantic change here, just better errors.
If a function says it takes a byte, and you pass it an int,
the compiler error now says that you need a byte, not
that you need a uint8.
Groundwork for rune.
R=ken2
CC=golang-dev
https://golang.org/cl/5300042
For example, if you are debugging an optimization
problem you can now run
GCFLAGS=-N gotest
This is a convention for make, not for the general build,
so it may go away or be done differently in the eventual
'go' command.
The plan is that people will be able to test their code for
rune safety by doing GCFLAGS=-r.
R=golang-dev, bradfitz, lvd
CC=golang-dev
https://golang.org/cl/5294042
Had been allowing it for use by fmt, but it is too hard to lock down.
Fix other packages not to depend on it.
R=r, r
CC=golang-dev
https://golang.org/cl/5266054
string literals used as package qualifiers are now prefixed with '@'
which obviates the need for the extra ':' before tags.
R=rsc, gri, lvd
CC=golang-dev
https://golang.org/cl/5129057
Fixes#2337.
Unfortunate sequence of events is:
1. maxcpu=2, mcpu=1, grunning=1
2. starttheworld creates an extra M:
maxcpu=2, mcpu=2, grunning=1
4. the goroutine calls runtime.GOMAXPROCS(1)
maxcpu=1, mcpu=2, grunning=1
5. since it sees mcpu>maxcpu, it calls gosched()
6. schedule() deschedules the goroutine:
maxcpu=1, mcpu=1, grunning=0
7. schedule() call getnextandunlock() which
fails to pick up the goroutine again,
because canaddcpu() fails, because mcpu==maxcpu
8. then it sees that grunning==0,
reports deadlock and terminates
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5191044
My previous CL:
changeset: 9645:ce2e5f44b310
user: Russ Cox <rsc@golang.org>
date: Tue Sep 06 10:24:21 2011 -0400
summary: gc: unify stack frame layout
introduced a bug wherein no variables were
being registerized, making Go programs 2-3x
slower than they had been before.
This CL fixes that bug (along with some others
it was hiding) and adds a test that optimization
makes at least one test case faster.
R=ken2
CC=golang-dev
https://golang.org/cl/5174045
Running test/garbage/parser.out.
On a 4-core Lenovo X201s (Linux):
31.12u 0.60s 31.74r 1 cpu, no atomics
32.27u 0.58s 32.86r 1 cpu, atomic instructions
33.04u 0.83s 27.47r 2 cpu
On a 16-core Xeon (Linux):
33.08u 0.65s 33.80r 1 cpu, no atomics
34.87u 1.12s 29.60r 2 cpu
36.00u 1.87s 28.43r 3 cpu
36.46u 2.34s 27.10r 4 cpu
38.28u 3.85s 26.92r 5 cpu
37.72u 5.25s 26.73r 6 cpu
39.63u 7.11s 26.95r 7 cpu
39.67u 8.10s 26.68r 8 cpu
On a 2-core MacBook Pro Core 2 Duo 2.26 (circa 2009, MacBookPro5,5):
39.43u 1.45s 41.27r 1 cpu, no atomics
43.98u 2.95s 38.69r 2 cpu
On a 2-core Mac Mini Core 2 Duo 1.83 (circa 2008; Macmini2,1):
48.81u 2.12s 51.76r 1 cpu, no atomics
57.15u 4.72s 51.54r 2 cpu
The handoff algorithm is really only good for two cores.
Beyond that we will need to so something more sophisticated,
like have each core hand off to the next one, around a circle.
Even so, the code is a good checkpoint; for now we'll limit the
number of gc procs to at most 2.
R=dvyukov
CC=golang-dev
https://golang.org/cl/4641082
The 512 MB array causes load delays on some systems.
Now that we have recover, we can do all the tests in
one binary, so that the delay is incurred just once.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5142044
Alex Brainman reports that this is the only test
that keeps us from running test/run.
R=alex.brainman, lucio.dere, bradfitz, hectorchu
CC=golang-dev
https://golang.org/cl/4777043
bug340.go:14:7: error: expected type
bug340.go:15:4: error: reference to undefined field or method ‘x’
bug350.go:12:1: error: redefinition of ‘m’
bug350.go:11:1: note: previous definition of ‘m’ was here
bug350.go:15:1: error: redefinition of ‘p’
bug350.go:14:1: note: previous definition of ‘p’ was here
bug351.go:12:6: error: non-name on left side of ‘:=’
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5127041
bug363.go:13:12: error: invalid context-determined non-integer type for shift operand
bug363.go:16:12: error: invalid context-determined non-integer type for shift operand
pointer.go:34:6: error: incompatible type in initialization (pointer to interface type has no methods)
pointer.go:36:6: error: incompatible type in initialization
method2.go:15:1: error: invalid pointer or interface receiver type
method2.go:16:1: error: invalid pointer or interface receiver type
method2.go:21:1: error: invalid pointer or interface receiver type
method2.go:22:1: error: invalid pointer or interface receiver type
method2.go:28:15: error: type ‘*Val’ has no method ‘val’
method2.go:33:11: error: reference to undefined field or method ‘val’
shift1.go:19:16: error: invalid context-determined non-integer type for shift operand
shift1.go:24:19: error: invalid context-determined non-integer type for shift operand
shift1.go:25:17: error: invalid context-determined non-integer type for shift operand
shift1.go:18:18: error: shift of non-integer operand
shift1.go:26:13: error: floating point constant truncated to integer
shift1.go:33:15: error: integer constant overflow
shift1.go:34:15: error: integer constant overflow
shift1.go:35:17: error: integer constant overflow
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5081051
Added a return to bug357.go to avoid an error which gccgo
reports but 6g does not.
bug353.go:16:14: error: reference to undefined identifer ‘io.ReadWriterCloser’
bug357.go:18:2: error: value computed is not used
bug358.go:14:11: error: imported and not used: ioutil
bug358.go:19:9: error: invalid use of type
bug359.go:25:14: error: redefinition of ‘a’
bug359.go:25:6: note: previous definition of ‘a’ was here
bug359.go:19:6: error: incompatible type in initialization (implicit assignment of ‘list.List’ hidden field ‘front’)
bug362.go:13:6: error: iota is only defined in const declarations
bug362.go:14:6: error: iota is only defined in const declarations
bug362.go:15:6: error: iota is only defined in const declarations
bug363.go:13:12: error: shift of non-integer operand
bug363.go:16:12: error: shift of non-integer operand
bug365.go:15:8: error: expected package
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5078046
bug349.go:12:14: error: expected ‘;’ or ‘}’ or newline
bug349.go:12:2: error: not enough arguments to return
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5081047
The algtype-based test broke when algtype
got a bit more fine-grained, so replace with
an explicit check for the invalid key types.
R=ken2
CC=golang-dev
https://golang.org/cl/5071041
The spec says that all methods are inherited from an anonymous
field. There is no exception for non-exported methods.
This is related to issue 1536.
R=rsc
CC=golang-dev
https://golang.org/cl/5012043
Was keeping a pointer to the labeled statement in n->right,
which meant that generic traversals of the tree visited it twice.
That combined with aggressive flattening of the block
structure when possible during parsing meant that
the kinds of label: code label: code label: code sequences
generated by yacc were giving the recursion 2ⁿ paths
through the program.
Fixes#2212.
R=lvd
CC=golang-dev
https://golang.org/cl/4960050
Does as much as possible in data layout instead
of during the init function.
Handles var x = y; var y = z as a special case too,
because it is so prevalent in package unicode
(var Greek = _Greek; var _Greek = []...).
Introduces InitPlan description of initialized data
so that it can be traversed multiple times (for example,
in the copy handler).
Cuts package unicode's init function size by 8x.
All that remains there is map initialization, which
is on the chopping block too.
Fixes sinit.go test case.
Aggregate DATA instructions at end of object file.
Checkpoint. More to come.
R=ken2
CC=golang-dev
https://golang.org/cl/4969051
Escape analysis was incorrectly assuming that
functions without bodies don't leak their
parameters. This meant that sync/atomic's
TestAddInt64 was allocating x on its stack,
and then x was not properly aligned for use
with the atomic 64-bit instructions. Obviously
we should figure out the alignment story on 5g
too, but this fix is correct and should restore the
build to 'ok'.
TBR=lvd
CC=golang-dev
https://golang.org/cl/4964047
-s now means *disable* escape analysis.
Fix escape leaks for struct/slice/map literals.
Add ... tracking.
Rewrite new(T) and slice literal into stack allocation when safe.
Add annotations to reflect.
Reflect is too chummy with the compiler,
so changes like these affect it more than they should.
R=lvd, dave, gustavo
CC=golang-dev
https://golang.org/cl/4954043
For now it's switch-on-and-offable with -s, and the effects can be inspected
with -m. Defaults are the old codepaths.
R=rsc
CC=golang-dev
https://golang.org/cl/4634073
Make the stack traces more readable for new
Go programmers while preserving their utility for old hands.
- Change status number [4] to string.
- Elide frames in runtime package (internal details).
- Swap file:line and arguments.
- Drop 'created by' for main goroutine.
- Show goroutines in order of allocation:
implies main goroutine first if nothing else.
There is no option to get the extra frames back.
Uncomment 'return 1' at the bottom of symtab.c.
$ 6.out
throw: all goroutines are asleep - deadlock!
goroutine 1 [chan send]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:22 +0x8a
goroutine 2 [select (no cases)]:
main.sel()
/Users/rsc/g/go/src/pkg/runtime/x.go:11 +0x18
created by main.main
/Users/rsc/g/go/src/pkg/runtime/x.go:19 +0x23
goroutine 3 [chan receive]:
main.recv(0xf8400010a0, 0x0)
/Users/rsc/g/go/src/pkg/runtime/x.go:15 +0x2e
created by main.main
/Users/rsc/g/go/src/pkg/runtime/x.go:20 +0x50
goroutine 4 [chan receive (nil chan)]:
main.recv(0x0, 0x0)
/Users/rsc/g/go/src/pkg/runtime/x.go:15 +0x2e
created by main.main
/Users/rsc/g/go/src/pkg/runtime/x.go:21 +0x66
$
$ 6.out index
panic: runtime error: index out of range
goroutine 1 [running]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:25 +0xb9
$
$ 6.out nil
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x22ca]
goroutine 1 [running]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:28 +0x211
$
$ 6.out panic
panic: panic
goroutine 1 [running]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:30 +0x101
$
R=golang-dev, qyzhai, n13m3y3r, r
CC=golang-dev
https://golang.org/cl/4907048
I converted this program yesterday and the output is the
same as it used to be, ignoring space, but the result is
not the best expression of the algorithm. The old {.section
Maybe} pieces are now {{with .Maybe}}, as a direct translation,
but I they should be {{if .Maybe}} as the output is just a
bool and there is no cascading.
I have verified that the output of the program is unaffected.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/4889053
It's already in old/template; make that build.
Update a couple of references to point to the old template.
They can be updated later.
Update goplay to use exp/template.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/4902046
// ERROR "pattern1" "pattern2"
means that there has to be one or more
lines matching pattern1 and then excluding
those, there have to be one or more lines
matching pattern2. So if you expect two
different error messages from a particular
line, writing two separate patterns checks
that both errors are produced.
Also, errchk now flags lines that produce
more errors than expected. Before, as long as
at least one error matched the pattern, all the
others were ignored.
Revise tests to expect or silence these
additional errors.
R=lvd, r, iant
CC=golang-dev
https://golang.org/cl/4869044
Some tests are significantly faster (50%), a few are slower (up to 30%).
Fannkuch is confusing: parallel code is a little slower for gc, non-parallel and all gccgo runs are faster.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/4830058
Drops mallocrep1.go back to a reasonable
amount of time. (154 -> 0.8 seconds on my Mac)
Fixes#2085.
R=golang-dev, dvyukov, r
CC=golang-dev
https://golang.org/cl/4811045
This is a core API change.
1) gofix misc src
2) Manual adjustments to the following files under src/pkg:
gob/decode.go
rpc/client.go
os/error.go
io/io.go
bufio/bufio.go
http/request.go
websocket/client.go
as well as:
src/cmd/gofix/testdata/*.go.in (reverted)
test/fixedbugs/bug243.go
3) Implemented gofix patch (oserrorstring.go) and test case (oserrorstring_test.go)
Compiles and runs all tests.
R=r, rsc, gri
CC=golang-dev
https://golang.org/cl/4607052
The spec was adjusted in commit df410d6a4842 to allow the
implicit assignment of strutures with unexported fields in
method receivers. This change updates the compiler.
Also moved bug322 into fixedbugs and updated golden.out
to reflect the removal of the last known bug.
Fixes#1402.
R=golang-dev, gri, rsc
CC=golang-dev
https://golang.org/cl/4526069
The code for converting negative floats was
incorrectly loading an FP control word from
the stack without ever having stored it there.
Thanks to Lars Pensjö for reporting this bug.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4515091
Previously, whether declaring a type which copied the structure of a type it was referenced in via a pointer field would work depended on whether you declared it before or after the type it copied, e.g. type T2 T1; type T1 struct { F *T2 } would work, however type T1 struct { F *T2 }; type T2 T1 wouldn't.
Fixes#667.
R=rsc
CC=golang-dev
https://golang.org/cl/4313064
Also, 6g was passing uninitialized
Node &n2 to regalloc, causing non-deterministic
register collisions (but only when both left and
right hand side of comparison had function calls).
Fixes#1728.
R=ken2
CC=golang-dev
https://golang.org/cl/4425070
go/types: update for export data format change
reflect: require package qualifiers to match during interface check
runtime: require package qualifiers to match during interface check
test: fixed bug324, adapt to be silent
Fixes#1550.
Issue 1536 remains open.
R=gri, ken2, r
CC=golang-dev
https://golang.org/cl/4442071
Interesting comparisons between old and new machine,
and relationship between gccgo and gc.
R=golang-dev, rsc1
CC=golang-dev
https://golang.org/cl/4430045
The list elements are already being allocated out of a
single memory buffer. We can drop the Link* pointer
following and the memory it requires, replacing it with
index operations.
The change also keeps a channel from containing a pointer
back into its own allocation block, which would create a
cycle. Blocks involved in cycles are not guaranteed to be
finalized properly, and channels depend on finalizers to
free OS-level locks on some systems. The self-reference
was keeping channels from being garbage collected.
runtime-gdb.py will need to be updated in order to dump
the content of buffered channels with the new data structure.
Fixes#1676.
R=ken2, r
CC=golang-dev
https://golang.org/cl/4411045
This CL changes the behavior of 'make install' and 'make test'
in the src/cmd directory and the src/pkg directory to have
each recursive make clean up after itself immediately.
It does the same in test/run, removing $F.$A and $A.out
(the common byproducts) between runs.
On machines with slow disks and aggressive kernel caching,
cleaning up immediately can mean that the intermediate
objects never get written to disk.
This change eliminates almost all the disk waiting during
all.bash on my laptop (a Thinkpad X201s with an SSD running Linux).
147.50u 19.95s 277.34r before
148.53u 21.64s 179.59r after
R=golang-dev, r, iant2
CC=golang-dev
https://golang.org/cl/4413042
Failing at compile time requires that for each conversion
between two interface types the compiler compare the sets of
unexported methods to see if they come from different
packages. Since this test will fail approximately never on
real code, and since it can't catch all cases of the problem,
I don't think it's worth testing in the compiler. This CL
changes this test to look for a run-time panic rather than a
compile-time error.
R=gri, rsc1, iant2, rsc
CC=golang-dev
https://golang.org/cl/4332041
chan.go:11:1: error: unexpected ‘}’ in channel type
chan.go:13:16: error: unexpected ‘)’ in channel type
chan.go:16:16: error: unexpected comma in channel type
R=golang-dev, rsc1
CC=golang-dev
https://golang.org/cl/4313055
bug323.go:18:3: error: reference to undefined field or method ‘Meth’
bug323.go:19:3: error: reference to undefined field or method ‘Meth2’
R=golang-dev, rsc1
CC=golang-dev
https://golang.org/cl/4280072
bug325.go:13:10: error: invalid indirect of ‘unsafe.Pointer’
bug325.go:14:31: error: reference to field ‘foo’ in object which has no fields or methods
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4313050
bug274.go:23:3: error: missing statement after label
bug274.go:25:3: error: missing statement after label
bug274.go:28:3: error: label ‘L2’ defined and not used
R=rsc
CC=golang-dev
https://golang.org/cl/4273114
label.go:30:1: error: label ‘L6’ already defined
label.go:28:1: note: previous definition of ‘L6’ was here
label.go:23:1: error: label ‘L4’ defined and not used
label.go:52:2: error: label ‘defalt’ defined and not used
label.go:17:1: error: label ‘L2’ defined and not used
label.go:26:1: error: label ‘L5’ defined and not used
label.go:20:1: error: label ‘L3’ defined and not used
label.go:14:1: error: label ‘L1’ defined and not used
label1.go:32:13: error: invalid continue label ‘L2’
label1.go:44:13: error: invalid continue label ‘L3’
label1.go:52:10: error: invalid break label ‘L4’
label1.go:55:13: error: invalid continue label ‘L4’
label1.go:65:9: error: invalid break label ‘L5’
label1.go:68:12: error: invalid continue label ‘L5’
label1.go:76:10: error: invalid break label ‘L1’
label1.go:79:13: error: invalid continue label ‘L1’
R=rsc
CC=golang-dev
https://golang.org/cl/4275078
Change unsafe.Pointer to be its own kind of
type, instead of making it equivalent to *any.
The change complicates import and export
but avoids the need to find all the places that
operate on pointers but should not operate on
unsafe.Pointer.
Fixes#1566. (a different way)
Fixes#1582.
R=ken2
CC=golang-dev
https://golang.org/cl/4264050
This change removes the special case which existed
for handling the initalization of the main package,
so that other modules named 'main' get properly
initialized when imported.
Note that gotest of main packages will break in most
cases without this.
R=rsc
CC=golang-dev
https://golang.org/cl/4190050
Also: renamed fixedbugs/bug322.go to fixedbugs/bug323.go
because we already have a bugs/bug322.go and bug322.dir.
R=rsc
CC=golang-dev
https://golang.org/cl/4219044
In line with other functions such as Fprintf, put the
thing to be written first.
Apologies for the breakages this is sure to cause.
R=rsc, gri, adg, eds, r2, aam
CC=golang-dev
https://golang.org/cl/4169042
Shame on me: I fixed the same bug in 6l in 8691fcc6a66e
(https://golang.org/cl/2609041) and neglected
to look at 5l and 8l to see if they were affected.
On the positive side, the check I added in that CL is the
one that detected this bug.
Fixes#1457.
R=ken2
CC=golang-dev
https://golang.org/cl/3981052
This aligns the naming scheme with the testing package and
also lets govet work on more logging calls.
R=rsc
CC=golang-dev
https://golang.org/cl/4001048
The sanity checking in pass 2 is wrong
when a select is offering to communicate in
either direction on a channel and neither case
is immediately ready.
R=ken2
CC=golang-dev
https://golang.org/cl/3991047
The old heap maps used a multilevel table, but that
was overkill: there are only 1M entries on a 32-bit
machine and we can arrange to use a dense address
range on a 64-bit machine.
The heap map is in bss. The assumption is that if
we don't touch the pages they won't be mapped in.
Also moved some duplicated memory allocation
code out of the OS-specific files.
R=r
CC=golang-dev
https://golang.org/cl/4118042
Close of closed channel panics.
Receive from closed channel never panics,
even if done repeatedly.
Fixes#1349.
Fixes#1419.
R=gri, iant, ken2, r, gri1, r2, iant2, rog, albert.strasheim, niemeyer, ejsherry
CC=golang-dev
https://golang.org/cl/3989042
There were duplicate closes and missing closes,
with the result that the program was rarely testing
as much as it seemed to be. Now it finishes.
R=r
CC=golang-dev
https://golang.org/cl/4008046
The recent linker changes broke NaCl support
a month ago, and there are no known users of it.
The NaCl code can always be recovered from the
repository history.
R=adg, r
CC=golang-dev
https://golang.org/cl/3671042
- Skip the gccgo tests if we don't have it
- Add -lm so nbody.c will compile
- Pass 2098 to the meteor test (cf. the shootout site)
R=rsc, r, iant
CC=golang-dev
https://golang.org/cl/3619042
cc: same
runtime: test cc alignment (required moving #define of offsetof to runtime.h)
fix bug260
Fixes#482.
Fixes#609.
R=ken2, r
CC=golang-dev
https://golang.org/cl/3563042
Specifically:
* lib/godoc:
- provide file set (FSet) argument to formatters where needed
* src/cmd:
- cgo, ebnflint, godoc, gofmt, goinstall: provide file set (fset) where needed
- godoc: remove local binary search with sort.Search (change by rsc),
extract file set for formatters
* src/pkg:
- exp/eval: remove embedded token.Position fields from nodes and replace
with named token.Pos fields; add corresponding Pos() accessor methods
- go/token: added file.Line(), changed signature of File.Position()
* test/fixedbugs/:
- bug206.go: change test to not rely on token.Pos details
* added various extra comments
* Runs all.bash
* gofmt formats all of src, misc w/o changes
* godoc runs
* performance:
- The new version of godoc consumes about the same space after indexing
has completed, but indexing is half the speed. Significant space savings
are expected from smaller ASTs, but since they are thrown away after a
file has been indexed, this is not visible anymore. The slower indexing
time is due to the much more expensive computation of line information.
However, with the new compressed position information, indexing can be
rewritten and simplified. Furthermore, computing the line info can be
done more efficiently.
New godoc, immediately after indexing completed (best of three runs):
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
44381 godoc 0.0% 0:38.00 4 19 149 145M 184K 148M 176M
2010/12/03 17:58:35 index updated (39.231s, 18505 unique words, 386387 spots)
2010/12/03 17:58:35 bytes=90858456 footprint=199182584
2010/12/03 17:58:36 bytes=47858568 footprint=167295224
Old godoc, immediately after indexing completed (best of three runs):
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
23167 godoc 0.0% 0:22.02 4 17 132 129M 184K 132M 173M
2010/12/03 14:51:32 index updated (24.892s, 18765 unique words, 393830 spots)
2010/12/03 14:51:32 bytes=66404528 footprint=163907832
2010/12/03 14:51:32 bytes=46282224 footprint=163907832
The different numbers for unique words/spots stem from the fact the the
two workspaces are not exactly identical. The new godoc maintains a large
file set data structure during indexing which (probably) is the reason
for the larger heap (90858456 vs 66404528) before garbage collection.
R=rsc, r
CC=golang-dev
https://golang.org/cl/3050041
Changed all uses of bytes.Add (aside from those testing bytes.Add) to append(a, b...).
Also ran "gofmt -s" and made use of copy([]byte, string) in the fasta benchmark.
R=golang-dev, r, r2
CC=golang-dev
https://golang.org/cl/3302042
I tried adding a Scale method to big.Int and it didn't make any noticeable
difference, so I'm removing my TODO.
Also got rid of a few obvious allocations that I missed earlier for a modest
improvement (~5%).
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/2711043
The new comparison rule was added to the spec by
changeset: 5605:33abb649cb63
user: Robert Griesemer <gri@golang.org>
date: Thu Jun 03 16:55:50 2010 -0700
files: doc/go_spec.html
description:
go spec: Base comparison compatibility on assignment compatibility.
Specifically:
- Simplified definition of comparison compatibility and folded into
section on comparison operators since it's only used there.
This is a small language change/cleanup. As a consequence:
- An interface value may now be compared against a non-interface value.
- Channels with opposite directions cannot be compared directly anymore
(per discussion with rsc).
R=rsc, r, iant, ken2
CC=golang-dev
https://golang.org/cl/1462041
but never implemented.
Fixes#1070.
R=ken2
CC=golang-dev
https://golang.org/cl/2116047
This test is supposed to test runtime behaviour. However,
gccgo is smart enough to see that the variables are local to
the package and that they never change. Add a function so
that gccgo thinks that the variables can in fact vary, so that
the test works at runtime as expected.
R=rsc
CC=golang-dev
https://golang.org/cl/2178041
The gccgo compiler does not always generate a "cannot use"
error message. It only does so for named types. Maybe that
should change, but in any case it is irrelevant for this test.
assign1.go:105:4: error: incompatible types in assignment (cannot use type A1 as type A)
assign1.go:107:5: error: incompatible types in assignment (cannot use type A as type A1)
assign1.go:112:4: error: incompatible types in assignment (cannot use type B1 as type B)
assign1.go:114:5: error: incompatible types in assignment (cannot use type B as type B1)
assign1.go:119:4: error: incompatible types in assignment (cannot use type C1 as type C)
assign1.go:121:5: error: incompatible types in assignment (cannot use type C as type C1)
assign1.go:126:4: error: incompatible types in assignment (cannot use type F1 as type F)
assign1.go:128:5: error: incompatible types in assignment (cannot use type F as type F1)
assign1.go:140:4: error: incompatible types in assignment (cannot use type M1 as type M)
assign1.go:142:5: error: incompatible types in assignment (cannot use type M as type M1)
assign1.go:147:4: error: incompatible types in assignment (cannot use type P1 as type P)
assign1.go:149:5: error: incompatible types in assignment (cannot use type P as type P1)
assign1.go:154:4: error: incompatible types in assignment (cannot use type S1 as type S)
assign1.go:156:5: error: incompatible types in assignment (cannot use type S as type S1)
assign1.go:158:6: error: incompatible types in assignment
assign1.go:159:6: error: incompatible types in assignment
assign1.go:160:5: error: incompatible types in assignment
assign1.go:161:5: error: incompatible types in assignment
assign1.go:162:6: error: incompatible types in assignment
assign1.go:163:6: error: incompatible types in assignment
assign1.go:165:6: error: incompatible types in assignment
assign1.go:166:6: error: incompatible types in assignment
assign1.go:167:5: error: incompatible types in assignment
assign1.go:168:5: error: incompatible types in assignment
assign1.go:169:6: error: incompatible types in assignment
assign1.go:170:6: error: incompatible types in assignment
assign1.go:172:6: error: incompatible types in assignment
assign1.go:173:6: error: incompatible types in assignment
assign1.go:174:5: error: incompatible types in assignment
assign1.go:175:5: error: incompatible types in assignment
assign1.go:176:6: error: incompatible types in assignment
assign1.go:177:6: error: incompatible types in assignment
assign1.go:179:6: error: incompatible types in assignment
assign1.go:180:6: error: incompatible types in assignment
assign1.go:181:5: error: incompatible types in assignment
assign1.go:182:5: error: incompatible types in assignment
assign1.go:183:6: error: incompatible types in assignment
assign1.go:184:6: error: incompatible types in assignment
assign1.go:186:6: error: incompatible types in assignment
assign1.go:187:6: error: incompatible types in assignment
assign1.go:188:5: error: incompatible types in assignment
assign1.go:189:5: error: incompatible types in assignment
assign1.go:190:6: error: incompatible types in assignment
assign1.go:191:6: error: incompatible types in assignment
assign1.go:193:6: error: incompatible types in assignment
assign1.go:194:6: error: incompatible types in assignment
assign1.go:195:5: error: incompatible types in assignment
assign1.go:196:5: error: incompatible types in assignment
assign1.go:197:6: error: incompatible types in assignment
assign1.go:198:6: error: incompatible types in assignment
assign1.go:200:6: error: incompatible types in assignment
assign1.go:201:6: error: incompatible types in assignment
assign1.go:202:5: error: incompatible types in assignment
assign1.go:203:5: error: incompatible types in assignment
assign1.go:204:6: error: incompatible types in assignment
assign1.go:205:6: error: incompatible types in assignment
assign1.go:207:6: error: incompatible types in assignment
assign1.go:208:6: error: incompatible types in assignment
assign1.go:209:5: error: incompatible types in assignment
assign1.go:210:5: error: incompatible types in assignment
assign1.go:211:6: error: incompatible types in assignment
assign1.go:212:6: error: incompatible types in assignment
R=rsc
CC=golang-dev
https://golang.org/cl/2163044
The gccgo library generates some garbage in the init routines
because it handles interfaces slightly differently. Since the
test sets MemStats.Alloc to 0, the first time the garbage
collector runs it goes negative and the test fails.
R=rsc, r2
CC=golang-dev
https://golang.org/cl/2110044
nonblock.go wants to test nonblocking operations on
synchronous channels, so it is inherently racy. This
introduces loops to make the race conditions much more likely
to succeed when using gccgo.
R=r
CC=golang-dev
https://golang.org/cl/2161043
gccgo does not handle 'new' specially here.
varerr.go:10:6: error: reference to undefined name ‘asdf’
varerr.go:12:6: error: invalid left hand side of assignment
R=rsc
CC=golang-dev
https://golang.org/cl/2139045
undef.go:12:6: error: reference to undefined name ‘x’
undef.go:13:6: error: reference to undefined name ‘x’
undef.go:14:6: error: reference to undefined name ‘x’
undef.go:22:25: error: reference to undefined name ‘y’
undef.go:42:11: error: reference to undefined name ‘v’
R=rsc
CC=golang-dev
https://golang.org/cl/2152045
vareq.go:10:25: error: expected ';' or '}' or newline
vareq1.go:9:24: error: expected ';' or newline after top level declaration
R=rsc
CC=golang-dev
https://golang.org/cl/2132045
With the recursive descent parser that gccgo uses, I think
that it doesn't make sense to try to match a statement where a
statement is not expected. If the construct is not a
statement, you will just get bizarre error messages.
topexpr.go:9:1: error: expected declaration
topexpr.go:14:1: error: expected declaration
topexpr.go:19:1: error: expected declaration
R=rsc, r2
CC=golang-dev
https://golang.org/cl/2175041
named1.go:40:11: error: argument 1 has incompatible type (cannot use type bool as type Bool)
named1.go:41:11: error: argument 1 has incompatible type (cannot use type bool as type Bool)
named1.go:43:7: error: incompatible types in assignment (cannot use type bool as type Bool)
named1.go:44:12: error: argument 4 has incompatible type (cannot use type Bool as type bool)
named1.go:46:4: error: incompatible types in assignment (cannot use type bool as type Bool)
named1.go:48:11: error: argument 1 has incompatible type (cannot use type bool as type Bool)
named1.go:50:7: error: incompatible types in assignment (cannot use type bool as type Bool)
named1.go:54:7: error: incompatible types in assignment (cannot use type bool as type Bool)
named1.go:60:7: error: incompatible types in assignment (cannot use type bool as type Bool)
named1.go:63:9: error: argument 1 has incompatible type (cannot use type bool as type Bool)
named1.go:64:4: error: incompatible types in assignment (cannot use type bool as type Bool)
named1.go:67:17: error: invalid type conversion (cannot use type Slice as type String)
R=rsc
CC=golang-dev
https://golang.org/cl/2146044
explicit.go:36:4: error: incompatible types in assignment (need explicit conversion)
explicit.go:41:4: error: incompatible types in assignment (type has no methods)
explicit.go:42:4: error: incompatible types in assignment (need explicit conversion)
explicit.go:45:5: error: incompatible types in assignment (need explicit conversion; missing method ‘N’)
explicit.go:48:9: error: invalid type conversion (need explicit conversion; missing method ‘N’)
explicit.go:51:4: error: incompatible types in assignment
explicit.go:51:7: error: invalid type conversion (need explicit conversion)
explicit.go:57:10: error: impossible type assertion: type does not implement interface (type has no methods)
explicit.go:62:10: error: impossible type assertion: type does not implement interface (incompatible type for method ‘M’ (different number of parameters))
explicit.go:67:5: error: incompatible type in initialization (type has no methods)
explicit.go:68:5: error: incompatible type in initialization (incompatible type for method ‘M’ (different number of parameters))
explicit.go:70:11: error: invalid type conversion (type has no methods)
explicit.go:71:11: error: invalid type conversion (incompatible type for method ‘M’ (different number of parameters))
R=rsc
CC=golang-dev
https://golang.org/cl/2139044
bug299.go:16:2: error: expected field name
bug299.go:17:2: error: expected field name
bug299.go:18:3: error: expected field name
bug299.go:25:9: error: expected receiver name or type
bug299.go:26:10: error: expected receiver name or type
bug299.go:27:9: error: expected receiver name or type
R=rsc
CC=golang-dev
https://golang.org/cl/2150044
Solves the (English) peg solitaire game. The board is represented
by a 1-dimensional array for easy representation of directions
with a single integer. The board's contents are chosen such that
it can be printed with a direct string() conversion.
R=r
CC=adg, golang-dev
https://golang.org/cl/2066042
bug284.go:33: error: invalid type conversion
bug284.go:36: error: invalid type conversion (cannot use type A2 as type A1)
bug284.go:37: error: invalid type conversion
bug284.go:38: error: invalid type conversion (cannot use type A1 as type A2)
bug284.go:56: error: invalid type conversion
bug284.go:59: error: invalid type conversion (cannot use type S2 as type S1)
bug284.go:60: error: invalid type conversion
bug284.go:61: error: invalid type conversion (cannot use type S1 as type S2)
bug284.go:71: error: invalid type conversion
bug284.go:74: error: invalid type conversion (cannot use type P2 as type P1)
bug284.go:75: error: invalid type conversion
bug284.go:76: error: invalid type conversion (cannot use type P1 as type P2)
bug284.go:96: error: invalid type conversion
bug284.go:99: error: invalid type conversion (cannot use type Q2 as type Q1)
bug284.go:101: error: invalid type conversion (cannot use type Q1 as type Q2)
bug284.go:111: error: invalid type conversion (different parameter types)
bug284.go:114: error: invalid type conversion (different parameter types)
bug284.go:115: error: invalid type conversion (different parameter types)
bug284.go:116: error: invalid type conversion (different parameter types)
bug284.go:134: error: invalid type conversion (incompatible type for method 'f' (different result types))
bug284.go:137: error: invalid type conversion (incompatible type for method 'f' (different result types))
bug284.go:138: error: invalid type conversion (incompatible type for method 'f' (different result types))
bug284.go:139: error: invalid type conversion (incompatible type for method 'f' (different result types))
bug284.go:149: error: invalid type conversion
bug284.go:152: error: invalid type conversion (cannot use type L2 as type L1)
bug284.go:153: error: invalid type conversion
bug284.go:154: error: invalid type conversion (cannot use type L1 as type L2)
bug284.go:164: error: invalid type conversion
bug284.go:167: error: invalid type conversion (cannot use type L2 as type L1)
bug284.go:168: error: invalid type conversion
bug284.go:169: error: invalid type conversion (cannot use type L1 as type L2)
bug284.go:179: error: invalid type conversion
bug284.go:182: error: invalid type conversion (cannot use type C2 as type C1)
bug284.go:183: error: invalid type conversion
bug284.go:184: error: invalid type conversion (cannot use type C1 as type C2)
R=rsc
CC=golang-dev
https://golang.org/cl/2136041
bug278.go:18: error: invalid left hand side of assignment
bug278.go:19: error: array is not addressable
bug278.go:21: error: invalid left hand side of assignment
bug278.go:22: error: invalid left hand side of assignment
R=rsc
CC=golang-dev
https://golang.org/cl/2122042
The gccgo compiler is smart enough to not make something which
is not used. Use global variables to defeat this
optimization.
R=rsc
CC=golang-dev
https://golang.org/cl/2129041
Another case where gccgo and gc report similar but not
identical errors for a recursive interface.
bug251.go:11: error: invalid recursive interface
R=rsc
CC=golang-dev
https://golang.org/cl/2094041
This introduces GC_ERROR to mark an error only issued by the
gc compiler. GCCGO_ERROR already exists to mark errors only
issued by the gccgo compiler. Obviously these should be used
sparingly.
bug195.go:9: error: interface contains embedded non-interface
bug195.go:12: error: interface contains embedded non-interface
bug195.go:15: error: interface contains embedded non-interface
bug195.go:18: error: invalid recursive interface
bug195.go:22: error: invalid recursive interface
R=rsc
CC=golang-dev
https://golang.org/cl/2040043
Also, if the header is bad, exit with a non-zero status.
Other calls to Brdline in the tree, by category:
Reading symbol name from object file:
./cmd/5l/obj.c:486: name = Brdline(f, '\0');
./cmd/6l/obj.c:535: name = Brdline(f, '\0');
./cmd/8l/obj.c:564: name = Brdline(f, '\0');
./libmach/sym.c:292: cp = Brdline(bp, '\0');
Reading archive header line (fixed, short):
./cmd/gc/lex.c:287: if((a = Brdline(b, '\n')) == nil)
./cmd/gc/lex.c:303: if((p = Brdline(b, '\n')) == nil)
Reading object file header line (fixed, short):
./cmd/ld/lib.c:421: line = Brdline(f, '\n');
Reading undefined symbol list (unused code):
./cmd/ld/lib.c:773: while((l = Brdline(b, '\n')) != nil){
Implementing Brdstr:
./libbio/brdstr.c:36: p = Brdline(bp, delim);
The symbol names ones will cause a problem loudly if they
fail: they'll error out with symbol name too long. This means
that you can't define an enormous struct without giving the
type a name and then stick it in an interface, because the
type's symbol name will be too long for the object file.
Since this will be a loud failure instead of a silent one,
I'm willing to wait until it comes up in practice.
R=r
CC=golang-dev
https://golang.org/cl/1982041
