alexfh added a comment. Kirill, first, thank you for working on this!
As discussed offline, the RefactoringModule interface should explicitly define: - separation of execution stages for each check: 1. preparation or execution planning - should figure out the set of affected translation units and what should be done for each of them 2. processing of affected translation units - ideally, this should be done in parallel, separate process per TU, and the interface should not prevent this 3. application of replacements or error reporting, if stage 2 detected that execution of refactoring is not possible - looks like this is not refactoring-specific and can be done by the clang-refactor framework - state transferred between stages (since they should allow for independent execution, potentially in multiple processes, so data should be in a serializable form) - data and facilities available to each stage (e.g. cross-reference index, AST of a certain translation unit, ability to register PPCallbacks, interface to pass data to the next stage, report results or errors) - basic interfaces for the facilities mentioned above. A failure to define these aspects would complicate introduction of multi-TU support and require significant changes to refactoring tools to follow a stricter interface. https://reviews.llvm.org/D24192 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
