Previously, gorename rejected all method renamings if it would
change the assignability relation.
Now, so long as the renaming was initiated at an abstract
method, the renaming proceeds, changing concrete methods (and
possibly other abstract methods) as needed. The user
intention is clear.
The intention of a renaming initiated at a concrete method is
less clear, so we still reject it if it would change the
assignability relation. The diagnostic advises the user to
rename the abstract method if that was the intention.
Additional safety checks are required: for each
satisfy.Constraint that couples a concrete type C and an
interface type I, we must treat it just like a set of implicit
selections C.f, one per abstract method f of I, and ensure the
selections' meanings are unchanged.
The satisfy package no longer canonicalizes types, since this
substitutes one interface for another (equivalent) one, which
is sound, but makes the type names random and the error
messages confusing.
Also, fixed a bug in 'satisfy' relating to map keys.
+ Lots more tests.
LGTM=sameer
R=sameer
CC=golang-codereviews
https://golang.org/cl/173430043
The main goroutine wasn't waiting for the two closed channels to drain.
Moral: with concurrency, never invent. D'oh.
LGTM=sameer
R=sameer
CC=golang-codereviews
https://golang.org/cl/178090043
Such messages are more informative when the error occurs deep within a script.
Also: add tool name to digraph's usage messages.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/173380043
Rewrite performed with this command:
sed -i '' 's_code.google.com/p/go\._golang.org/x/_g' \
$(grep -lr 'code.google.com/p/go.' *)
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/170920043
(They may contain any character, after all.)
Also, allow but don't require parens and stars.
e.g. (*"encoding/json".Decoder).Decode or "encoding/json".Decoder.Decode
but not encoding/json.Decoder.Decode.
Since -from queries are now Go expressions, we use the Go parser.
(Thanks to Rog Peppe for the suggestion.)
LGTM=sameer
R=sameer
CC=golang-codereviews, gri, rogpeppe
https://golang.org/cl/154610043
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
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
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 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
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
LookupFieldOrMethod now also decides whether a found
method is actually in the method set. Simplifies call
sites. Added corresponding API tests.
TODO (separate CL): Decide what the correct value for
the indirect result should be (as required for code
generation). For now, the result value for indirect
is unchanged from before if a field/method is found.
Fixesgolang/go#8584.
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/132260043
e.g. chmod +w, checkout.
Also: add a TIPS section to the documentation.
LGTM=crawshaw
R=crawshaw, gri
CC=golang-codereviews
https://golang.org/cl/136780044
PackageInfo:
- deleted IsType
- inlined + deleted: ValueOf, TypeCaseVar, ImportSpecPkg
- on failure, TypeOf accessor now returns nil (was: panic)
go/ssa: avoid extra map lookups by using Uses or Defs directly when safe to do so,
and keeping the TypeAndValue around in expr0().
LGTM=gri
R=gri, pcc
CC=golang-codereviews
https://golang.org/cl/107650043
