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
..
main.go	cmd/gorename: support renaming of methods with consequences for other types, iff initiated at an abstract method.	2014-12-04 09:37:50 -05:00