1
0
mirror of https://github.com/golang/go synced 2024-10-02 00:18:32 -06:00
Commit Graph

8 Commits

Author SHA1 Message Date
Alan Donovan
25bacdead0 refactor/rename: fix build breakage (due to go/types version skew)
Change-Id: Id798ff0acdc9d4a83efe1b760ca32ede6a1aa5bb
Reviewed-on: https://go-review.googlesource.com/14132
Reviewed-by: Alan Donovan <adonovan@google.com>
2015-08-31 21:13:35 +00:00
Alan Donovan
03e05ec5a5 refactor/rename: eliminate dependency on refactor/lexical package
so that we can delete that package.

lexicalLookup reconstructs the lexical scope from the existing tree of
types.Scope blocks, using source position information to determine
which prefix of declarations are visible.  (Inspired by Russ's
lookupAtPos in github.com/rsc/grind/grinder.)

forEachLexicalRef implements the part of the recursion from
refactor/lexical that enumerates the ast.Idents that use lexical
lookup.  (I would still like to eliminate this redundant logic by
having go/types record environments, as in CL 9493.)

Change-Id: I040ab33b508aad2dc68fd48850fe92ec072045d1
Reviewed-on: https://go-review.googlesource.com/9544
Reviewed-by: Sameer Ajmani <sameer@golang.org>
2015-08-31 20:58:11 +00:00
Alan Donovan
4d45c85020 go/types: expose IsInterface predicate, eliminating 6 copies
Change-Id: I3704d7bd7a11f691c66556c1b77ef79a503d2fe9
Reviewed-on: https://go-review.googlesource.com/2173
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2015-01-21 18:49:27 +00:00
Michael Matloob
796e50ba32 cmd/mvpkg: a package moving tool
This change adds a command mvpkg that will move a given package and
update all its imports. It uses similar logic to gorename to update
the imports.

Change-Id: Iebbd0b4c93c2302b0a71c3b99c68f6778106012a
Reviewed-on: https://go-review.googlesource.com/1973
Reviewed-by: Alan Donovan <adonovan@google.com>
2015-01-14 17:37:29 +00:00
Alan Donovan
c6ec5ea66d cmd/gorename: support renaming of methods with consequences for other types, iff initiated at an abstract method.
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
2014-12-04 09:37:50 -05:00
Alan Donovan
fb44a24d4c refactor/rename: fix crash when renaming anonymous struct field that's a qualified reference
(or a pointer, or both).

+ test

Fixes bug 8924

LGTM=sameer
R=dominik.honnef, sameer
CC=<dominik.honnef, golang-codereviews
https://golang.org/cl/158920043
2014-11-10 16:03:40 -05:00
Andrew Gerrand
5ebbcd132f go.tools: use golang.org/x/... import paths
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
2014-11-10 08:50:40 +11:00
Alan Donovan
74021b4175 cmd/gorename: a precise, type-aware renaming tool for Go identifiers.
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
2014-09-23 10:23:04 -04:00