RefactoringTools / HaRe

The Haskell Refactoring Tool
http://www.cs.kent.ac.uk/projects/refactor-fp/
Other
139 stars 32 forks source link

Incorrect renaming of function parameters #41

Closed Lysxia closed 7 years ago

Lysxia commented 7 years ago
module A where
  f x = let g = g in x

Rename x to g is successful, but shouldn't be as the result is not equivalent:

module A where
  f g = let g = g in g
alanz commented 7 years ago

Interesting. I am comparing the current implementation to the one in https://www.cs.kent.ac.uk/projects/refactor-fp/publications/Huiqing-thesis.pdf, and I see the in-place checking for each occurrence has got lost somewhere along the way.

In particular

"Inside the function condChecking' , three conditions are checked. The first condition ensures that the new name does not exist in the same binding group, where the function declaredVarsInSameGroup (from the API) is used to fetch all the variable names declared in the same binding group where x is declared. The second condition checks whether the new name will intervene between the existing uses of y and its bindings, where function hsFreeAndDeclaredNames is used to fetch the free and declared variables in the argument syntax phrase. The third condition checks whether the new name is declared somewhere between the declaration of identifier to be renamed and one of its call-sites, and function hsVisibleNames is used to collect the names which are declared in the given syntax phrase and visible to one of the call-sites of the identifier. In the local functions, including inMatch, inPattern, and inAlt , the values defaultPNT and/or [ ] are used to shadow those variables declared in the same syntax phrase but in an outer scope."

Looks like a complete revalidation against the original will be required, for the various refactorings.

alanz commented 7 years ago

Closed via https://github.com/RefactoringTools/HaRe/pull/44