Windows doesn't regard "/go/src" as an absolute path,
so we must explicitly define the virtual IsAbsPath method.
LGTM=gri
R=gri, sameer
CC=golang-codereviews
https://golang.org/cl/147100043
...by using buildutil.ContainingPackage instead of guessImportPath.
The former should be more portable.
(I meant to do this earlier, so this is also a nice cleanup.)
LGTM=gri
R=gri, sameer
CC=golang-codereviews
https://golang.org/cl/148050043
The 'parents' field is documented to be blank if there's only one
simple parent. We want 'p1node', which is the hex commit of the
first parent.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/142530043
Also add a added=true addition that I seemed to think was
previously missing.
Breaking this out of previous big CL.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/146080043
See the usage message in main.go for orientation.
To the best of my knowledge, the tool implements all required
soundness checks, except:
- the dynamic behaviour of reflection is obviously undecidable.
- it rejects method renamings that change the "implements" relation.
It should probably be more aggressive.
- actually it only checks the part of the "implements" relation
needed for compilation. Understanding the dynamic behaviour
of interfaces is obviously undecidable.
- a couple of minor gaps are indicated by TODO comments.
Also:
- Emacs integration.
- tests of all safety checks and (some) successful rewrites.
LGTM=dominik.honnef, sameer
R=gri, sameer, dominik.honnef
CC=golang-codereviews
https://golang.org/cl/139150044
- ParseFile (core of go/loader's parseFiles(); also used by refactor/rename)
- ContainingPackage (core of Oracle's guessImportPath; also used by refactor/rename)
- Accessors for effective "methods" of build.Context:
FileExists, OpenFile, IsAbsPath, JoinPath.
LGTM=sameer
R=dave, sameer
CC=golang-codereviews, gri
https://golang.org/cl/146120043
The type checker does not currently report the set of pairs of
types that are tested for assignability (though gri and I
agree that it should). This information is useful for many
applications. For example, refactoring tool needs to know the
minimal set of interface satisfaction constraints that must be
preserved during a refactoring.
This package is a stopgap measure to deduce the same
information using another pass. Unlike go/types, it is not
robust against inputs containing type errors.
LGTM=sameer
R=gri, sameer
CC=golang-codereviews
https://golang.org/cl/136470043
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
