1
0
mirror of https://github.com/golang/go synced 2024-11-05 19:56:11 -07:00
Commit Graph

10 Commits

Author SHA1 Message Date
Konstantin Shaposhnikov
8ea9d46069 refactor/rename: do not allow a new name to be a keyword
Fixes golang/go#16535

Change-Id: I46f9b9530e25bb286557712a7969715f8dde99b9
Reviewed-on: https://go-review.googlesource.com/25343
Reviewed-by: Alan Donovan <adonovan@google.com>
2016-08-20 16:15:16 +00:00
Alan Donovan
542ffc7e75 tools: switch to standard go/types at tip
A few files have been forked and tagged "go1.5,!go1.6" to work around
minor API changes between the two types packages:
- constant.Value.String() in oracle/describe.go and its tests;
- constant.ToInt must now be called before constant.Int64Val.
- types.Config{Importer: importer.Default()} in a number of places
- go/types/typeutil/import_test.go uses lowercase names to avoid 'import "C"'.

Files in go/types/typesutil, missing from my previous CL, have been
tagged !go1.5; these files will be deleted in February.

All affected packages were tested using 1.4.1, 1.5, and ~1.6 (tip).

Change-Id: Iec7fd370e1434508149b378438fb37f65b8d2ba8
Reviewed-on: https://go-review.googlesource.com/18207
Reviewed-by: Robert Griesemer <gri@golang.org>
2016-01-06 22:15:26 +00:00
Alan Donovan
2477c0d578 x/tools/...: fork and tag !1.5 all files that use go/types et al
This change will ensure that the tree continues to work with go1.4.1.

All files continue to depend on golang.org/x/tools/go/types, but in a
follow-up change, I will switch the primary files to depend on the
standard go/types package.  Another (smaller) set of files will be
forked and tagged, this time !1.6, due to API differences between the
two packages.

All tests pass using 1.4.1, 1.5, and ~1.6 (tip).

Change-Id: Ifd75a6330e120957d646be91693daaba1ce0e8c9
Reviewed-on: https://go-review.googlesource.com/18333
Reviewed-by: Robert Griesemer <gri@golang.org>
2016-01-06 20:40:09 +00:00
Peter Collingbourne
4f8578d2c0 astutil: move to go/ast/astutil
Change-Id: I9a45bfc07613eb2210081d306d71f0a4d152eda5
Reviewed-on: https://go-review.googlesource.com/2592
Reviewed-by: Alan Donovan <adonovan@google.com>
2015-01-13 15:47:47 +00:00
Alan Donovan
4f13714aca astutil: add Unparen utility, eliminating 7 copies.
Change-Id: I824328c275bd6198a57edd64bf72cb2cf0490a68
Reviewed-on: https://go-review.googlesource.com/2172
Reviewed-by: Chris Manghane <cmang@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2014-12-29 22:24:57 +00: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
d73c11bfcb refactor/rename: make -from syntax support string literals for complex import paths.
(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
2014-10-31 15:39:22 -04:00
Alex Brainman
181e280a22 refactor/rename: use filepath.ToSlash everywhere to fix windows tests
Fixes golang/go#8823.

LGTM=adonovan
R=golang-codereviews, gobot, adonovan
CC=golang-codereviews
https://golang.org/cl/142660043
2014-10-23 09:45:47 +11:00
Alan Donovan
a69ece7231 refactor/rename: attempt to fix windows build...
...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
2014-09-24 16:18:58 -04: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