The Uses, Defs and Scope information provided by go/types is
inadequate for answering "what if?" queries about the
structure of the lexical environment.
In this code, for example,
var x int
func f() {
print(x)
x := ""
print(x)
}
the two referring Idents x appear at the same lexical depth,
inside the function f's Scope object, yet they resolve to
different objects.
This package associates a lexical.Environment instance with
every reference to capture these differences. Each
environment is a linked list of enclosing Blocks, and for each
block, a number indicating what prefix of its bindings are
visible. (Zero for the first 'x' reference above, 1 for the
second.)
+ Smoke test over stdlib.
This functionality could be integrated with the type checker
in lieu of the not-so-useful types.Info.Scopes data, at little
extra cost in code or in running time/space. We should talk
about that.
LGTM=sameer
R=gri, sameer
CC=golang-codereviews
https://golang.org/cl/143790043
Nodes in a strongly connected component (which includes most
stdlib packages) appear in results of both "forward" and
"reverse" searches from any other node in the same SCC.
LGTM=sameer
R=sameer
CC=golang-codereviews, gri
https://golang.org/cl/136470044
This was a hold-over from when we removed install counts years ago.
All the Package entities are well-formed these days.
LGTM=dsymonds
R=dsymonds
CC=golang-codereviews
https://golang.org/cl/138620043
Previously type errors were reported via the web interface but
not logged, but this led to confusion as to why SSA
construction and/or pointer analysis were not attempted.
LGTM=gri
R=gri, bradfitz
CC=golang-codereviews
https://golang.org/cl/136660043
Today I learned that getElementByClass returns an
HTMLContainer, not an array, so the for loop was iterating its
properties, which include:
- the methods of the type, which were filtered out by the condition;
- the array-like integer indices of the elements, which we want;
- the ids of the same elements (!), which we weren't expecting.
The net result is that various functions were called twice,
causing the tree to be double-populated and clicks to cause
and expand+collapse.
It's a miracle to me that any JS program even approximately works.
Fixesgolang/go#8237
LGTM=bradfitz
R=gri, bradfitz
CC=golang-codereviews
https://golang.org/cl/141540043
The needMethods cache logic was wrong: it would treat any
previous call as a cache hit, even if 'skip' was true for that
call. As a result it could fail to generate methods for some
'skip' types, i.e. anonymous structs.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/144750043
This CL is the first refactoring automated by "gorename". :)
Though I had to update the comments and run 'hg gofmt'. :(
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/142930043
It now has a main() function, which was confusing the logic to find the entry point.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/142860044
To avoid breaking URLs, we redirect /src/pkg/* to /src/*.
The URL /pkg is now the "directory" /src, which triggers the
"Packages" index.
All other references to "src/pkg" are now gone,
except a number in the namespace documentation which are
probably still illustrative.
Tested: go test cmd/godoc godoc
Manual inspection of src and src/pkg pages.
with GOROOT and GOPATH packages
-analysis
/AUTHORS file URL still works
LGTM=bradfitz, adg
R=bradfitz, adg
CC=golang-codereviews
https://golang.org/cl/141770044
Refactoring tools can use this to determine an upper bound on
the set of packages potentially affected by a refactoring.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/141310043
This function has been copied at least 6 times throughout
go.tools. This implementation is superior since it does
all I/O through the virtualized go/build file system, and it
is highly parallel (and much faster).
We expose two flavours, simple (for existing tests) and
parallel (for high-performance tools such as gorename).
This CL creates the go/buildutil package, which is intended for
utilities related to go/build.
+ test.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/137430043
Documentation change only. The binary will not be installed
using the "go tool" mechanism.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/133710046
- for unused packages where base(package path) != package name
- for conflicts between imported packages or dot-imported objects
and local declarations
Per suggestions from adonovan, inspired by the gc error messages.
LGTM=adonovan
R=adonovan, bradfitz
CC=golang-codereviews
https://golang.org/cl/135550043
(godoc is excluded from this CL since it will continue to use
/src/pkg in its URL namespace, making the necessary cleanup
more subtle.)
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/141770043
... since it already caught a problem and was fixed in
hg rev 0b99c2137ccc.
I pushed this live already just so don't get a whole column of
fail that might hide other issues. Real users have USER set
anyway. (Perhaps we should set it for all our builders?)
LGTM=adg
R=golang-codereviews
CC=adg, dave, golang-codereviews, minux
https://golang.org/cl/137180043
Missed comment from previous code review.
Next up: execution tests so this won't happen again
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/134480043
Improve the generated code by using a const instead of a var for the names string.
This requires some refactoring to get neat const() and var() blocks.
Also change the generate map code go use a single sliced string, to reduce the
size of the compiled representation (only one string value).
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/135450044
Otherwise when running -386 and -amd64 on the same machine
with both copies of TDM-GCC installed (the installer wizard lets
you choose which one, and you can do both options in two
different install attemps), one previously got this error when
using the 64-bit gcc with a 386 build:
--- FAIL: TestStdcallAndCDeclCallbacks (0.12s)
panic: Failed to load C:\Users\WINDOW~1\AppData\Local\Temp\1\TestCDeclCallback960696761\test.dll: %1 is not a valid Win32 application. [recovered]
panic: Failed to load C:\Users\WINDOW~1\AppData\Local\Temp\1\TestCDeclCallback960696761\test.dll: %1 is not a valid Win32 application.
goroutine 81490 [running]:
runtime.panic(0x5b8c00, 0x1390d4e0)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/panic.c:130 +0xed fp=0x12d99f78 sp=0x12d99f24
testing.func·006()
c:/go/src/pkg/testing/testing.go:421 +0x147 fp=0x12d99fd0 sp=0x12d99f78
----- stack segment boundary -----
runtime.panic(0x5b8c00, 0x1390d4e0)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/panic.c:98 +0x17a fp=0x12155e98 sp=0x12155e44
syscall.MustLoadDLL(0x1390b7c0, 0x4a, 0x2)
c:/go/src/pkg/syscall/dll_windows.go:62 +0x6c fp=0x12155eb8 sp=0x12155e98
runtime_test.(*cbTest).run(0x12155f24, 0x1213cc00, 0x1390b7c0, 0x4a)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/syscall_windows_test.go:399 +0x36 fp=0x12155ef4 sp=0x12155eb8
runtime_test.TestStdcallAndCDeclCallbacks(0x1213cc00)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/syscall_windows_test.go:448 +0x28e fp=0x12155fac sp=0x12155ef4
TBR=cmang
R=cmang
CC=adg, golang-codereviews
https://golang.org/cl/141070043
Refactor a little to make testing easier.
Add golden tests and a check fo splitIntoRuns, which is the subtlest piece.
Still to come: execution tests.
Also fix a few issues in the generated code.
LGTM=gri
R=gri
CC=golang-codereviews, josharian
https://golang.org/cl/134450044
Creating a new disk is the major latency cost of creating a
new instance. If we reuse a previous disk image, the VM and
CoreOS boot much quicker and start building again.
So add a mode where we don't mark the disk as delete-on-death
when we create it, and we search for a suitably-named existing
one on creation and try to reuse it.
It's a cache, essentially. It's still stateless.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/135410043
Then make the coordinator and linux environment Makefiles have
an upload target. Amusingly, this actually worked: the Docker
images now tar + compress + upload over HTTP all in a stream,
without even knowing how large the resulting tar.gz will be until
it's done uploading.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/140200043
This tool creates String methods from constant definitions.
It's a time-saver designed to be used from go generate.
The methods generated are efficient, more so than one
is likely to create by hand.
Given
package date
type Day int
const (
Monday Day = iota
Tuesday
Wednesday
Thursday
Friday
Saturday
Sunday
)
the command
stringer -type Day
will create the file day_string.go containing
package date
import "fmt"
var (
_Day_indexes = []uint8{6, 13, 22, 30, 36, 44, 50}
_Day_names = "MondayTuesdayWednesdayThursdayFridaySaturdaySunday"
)
func (i Day) String() string {
if i < 0 || i >= Day(len(_Day_indexes)) {
return fmt.Sprintf("Day(%d)", i)
}
hi := _Day_indexes[i]
lo := uint8(0)
if i > 0 {
lo = _Day_indexes[i-1]
}
return _Day_names[lo:hi]
}
There are several strategies for the created method chosen according to
the structure of the sequence of constants.
Handles integer types only, both signed and unsigned. That's probably
all that is needed.
Tests to follow, but the test structure will be large so sending this out
separately. The code has been heavily hand-tested but there are
some bugs. Don't depend on this until the tests are installed.
LGTM=gri
R=gri, josharian
CC=golang-codereviews
https://golang.org/cl/136180043
Remove subversion & use newer version of the builder which
makes -verbose direct all.bash output to stdout/stderr.
LGTM=cmang
R=adg, cmang
CC=golang-codereviews
https://golang.org/cl/140910044
