[TheLoneWolfling]

I always thought that refactoring tools should be compilers.

That way you can reuse all of the parsing code / DCE code / flow analysis / etc / etc.

The extra mapping is something a "normal" (i.e. single-language) refactorer has to do anyways. Assuming its a half-decent refactoring tool its not just doing a find-replace.

The subtle differences / drawbacks you mention a compiler also has to deal with. Actually, everything you mention a compiler also has to deal with. You could say the same about compilers (there's no actual need for an IR with a compiler, for instance. You can operate on the AST directly. And you don't need to build an IR rich enough to keep semantics in all languages unless you're supporting multiple languages. Etc. Etc.) And yet we have GCC.

[JnRouvignac]

I agree the drawbacks equally apply to GCC. I agree a simple compiler does not need an IR. Some compiler optimisations cannot exist without an IR.

However I was wondering where a refactoring tool would need an IR. I found one: a CFG. For this, I need a three-address code representation. As a hypothesis, let's suppose I can build one that is independent from the input language. Once I have found how to refactor it, I then need to describe which code must be rewritten to what, in the input langage. This is the part where I find it very hard to do. I have the impression it will fall short here.

That would be an interesting experiment :)