Hello,<div><br></div><div>I've not touched the ARC code much yet (shock there ;] ) so let me know if I'm missing anything.</div><div><br></div><div>Currently ARCMigrate has code that heavily depends on datastructures and logic provided by the Frontend library (CompilerInstance, etc). This seems reasonable, certainly the Rewrite library and CodeGen library also have such a dependence. However, the Frontend library *also* depends on ARCMigrate which is down right confusing. This isn't just with header file #includes, the CMake files have each library depending on the other. Either way, seemed like a problem and layering violation.</div>
<div><br></div><div>When I looked more closely, the Frontend was only barely using anything from ARCMigrate, it just had special code to dispatch to magic routines there and do the migration steps. This seemed a bit ad-hoc, and bypassed the entire FrontendAction system that the other libraries use to managed the dependencies: FrontendTools depends on everyone and builds their concrete FrontendAction subclasses, everyone depends on Frontend in order to implement their concrete FrontendAction subclasses. This patch moves the ARCMigration code to the same pattern. It implements FrontendAction subclasses for each of the tools, and those are selected from the options in FrontendTools. That way FrontendTools is what depends on ARCMigrate, breaking the cycle. I also think its cleaner design than the previous version. Thoughts? This look like a reasonable approach?</div>