This patch removes usage of FinalPhase from anywhere outside of the scope where it is used to do argument handling.
It also adds argument based trimming of the Phase list pulled out of the Types.def table.
Details
- Reviewers
compnerd aaron.ballman - Commits
- rGe5ade767e5d1: [NFC][clang] Adding argument based Phase list filtering to getComplicationPhases
rL368734: [NFC][clang] Adding argument based Phase list filtering to getComplicationPhases
rC368734: [NFC][clang] Adding argument based Phase list filtering to getComplicationPhases
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Driver/Driver.cpp | ||
---|---|---|
3220 | Why do you need this compound statement? | |
clang/lib/Driver/Types.cpp | ||
313–315 | How about: llvm::copy_if(PhaseList, std::back_inserter(P), [](phases::ID Phase) { return Phase <= phases.Preprocess; }); Similar below. | |
348–349 | P = PhaseList; ? Or does P come in with data already in it, in which case, llvm::copy() is a better choice. |
clang/lib/Driver/Driver.cpp | ||
---|---|---|
3220 | I think the diff I posted here was a little bit off. I will update. |
clang/lib/Driver/Types.cpp | ||
---|---|---|
313–315 | That could work. I was using llvm::remove_if before and ran into some problematic behavior. |
clang/lib/Driver/Driver.cpp | ||
---|---|---|
3219–3220 | @aaron.ballman How's this look to you now? I have another NFC patch coming up that will move this entire block into its a separate function. I think finally this Drive::BuildActions code can have the code that handles and does things with various arguments separate from the actual job phase pipeline setup code. |
clang/include/clang/Driver/Types.h | ||
---|---|---|
107 | This really makes things confusing, perhaps renaming getCompilationPhases to getCompletePhaseList or something might make it less confusing? Although, I suppose that you do have follow up patches to improve this. |
clang/include/clang/Driver/Types.h | ||
---|---|---|
107 | I'm mainly going by the original name. But I can certainly do this in a followup patch. Actually I'd prefer to not do it here, and address this in a patch where I remove the other getFinalPhase method from the Driver class. |
This really makes things confusing, perhaps renaming getCompilationPhases to getCompletePhaseList or something might make it less confusing? Although, I suppose that you do have follow up patches to improve this.