Fixesgolang/go#21055.
Change-Id: I126cef4496c15424048e39b2af111c95580b90fb
Reviewed-on: https://go-review.googlesource.com/49390
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Set the env variable to only include the correct gopath in the test.
Fixesgolang/go#20805
Change-Id: I496ed5c60278e508016f915cf53a115cc3c222ae
Reviewed-on: https://go-review.googlesource.com/47410
Reviewed-by: Alan Donovan <adonovan@google.com>
Previous implementation will overwrite files the import "C" with the
cgo preprocessing and renaming. Rename will now emit an error when
rename must edit files that import "C". Will also emit more useful
error when using -offset in a "C" importing file.
Fixesgolang/go#17839
Change-Id: I072100b22197ec145b56d727feca58be7529e359
Reviewed-on: https://go-review.googlesource.com/45930
Reviewed-by: Alan Donovan <adonovan@google.com>
The user may specify the diff tool using the -diffcmd flag.
+ test.
Also:
- eliminate redundant DryRun flag
- simplify Verbose messages using log.SetPrefix
Fixes issue #13355
Change-Id: I917edc73e31ddf0f5d5b9b30c43f826465529da1
Reviewed-on: https://go-review.googlesource.com/18208
Reviewed-by: Michael Matloob <matloob@golang.org>
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
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
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
