It's unlikely to affect any extant code, but I wanted to make this API change
before digging in for a rewrite.
R=rsc
CC=golang-dev
https://golang.org/cl/2112041
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
Not a bug per-se, the issue is that the fmt.Sprintf method inside the
ByteSize.String() method ends up calling itself to generate the String
representation of the ByteSize value. Infinite loops are bad.
Updated as per review comments
R=r
CC=golang-dev
https://golang.org/cl/1974046
Two tests start a goroutine which runs exportSend, and then
the tests run importReceive. exportSend creates an export
channel. importReceive asks to receive values on that
channel. Because exportSend runs in a separate goroutine,
it's possible for the export client to receive the request for
values on the channel, from importReceive, before the
goroutine actually creates the export channel. That causes an
error: "export: no such channel: exportedSend". This patch
avoids the race by creating the export channel before starting
the goroutine.
There does not seem to be a similar race condition in the
tests which send data in the other direction.
R=r
CC=golang-dev
https://golang.org/cl/2026045
End the charade (farce?) that we are using upload.py unaltered.
Cut all the unused stuff.
Indent using tabs to match the rest of the file.
Next: rewrite MercurialVCS to use mercurial package,
to avoid overhead of forking off a new hg command
multiple times for every file. And parallelize upload.
R=gri
CC=golang-dev
https://golang.org/cl/2009046
- refine/define Scope, Object, and Type structures
(note: scope.go has the addition of types, the rest is only re-organized
for better readability)
- implemented top-level of type checker:
resolve global type declarations (deal with double decls, cycles, etc.)
- temporary hooks for checking of const/var declarations, function/method bodies
- test harness for fine-grained testing (exact error locations)
with initial set of tests
This is a subset of the code for easier review.
R=rsc
CC=golang-dev
https://golang.org/cl/1967049
Based on the observation that a great number of the types that
are copied or compared in interfaces, maps, and channels are
word-sized, this uses specialized copy and equality functions
for them that use a word instead of 4 or 8 bytes. Seems to yield
0-6% improvements in performance in the benchmarks I've run.
For example, with the regexp benchmarks:
Before:
regexp.BenchmarkLiteral 500000 3.26 µs/op
regexp.BenchmarkNotLiteral 100000 13.67 µs/op
regexp.BenchmarkMatchClass 100000 18.72 µs/op
regexp.BenchmarkMatchClass_InRange 100000 20.04 µs/op
regexp.BenchmarkReplaceAll 100000 27.85 µs/op
After:
regexp.BenchmarkLiteral 500000 3.11 µs/op
regexp.BenchmarkNotLiteral 200000 13.29 µs/op
regexp.BenchmarkMatchClass 100000 17.65 µs/op
regexp.BenchmarkMatchClass_InRange 100000 18.49 µs/op
regexp.BenchmarkReplaceAll 100000 26.34 µs/op
R=rsc
CC=golang-dev
https://golang.org/cl/1967047
