[clang] [flang] [flang][driver] Add pre-processing type to `.i` (pre-processed) files (PR #104664)
Andrzej Warzyński via cfe-commits
cfe-commits at lists.llvm.org
Mon Aug 26 02:59:09 PDT 2024
banach-space wrote:
Apologies for the delay, I am OOO 😅
I've had another look and I think that I better understand what the issue is. It is important to distinguish two input types that we are dealing with here:
* `-x f95-cpp-input` - Fortran input _before_ pre-processing,
* `-x f95` - Fortran input _after_ pre-processing
This PR updates the definition of the latter to also include pre-processing, which is counter-intuitive. However, given that the pre-processor is something unique to every driver (i.e. not defined by the standard itself), some flexibility is obviously required.
In this case, IIUC, the driver makes an assumption that **is valid for C-like inputs**, but **invalid for Fortran inputs**. Specifically, it assumes that _after_ preprocessing, no pre-processing is required and drops all the flags considered as specific to pre-processing (e.g. `-I` flags). While that works for C header files (which get "copied" into files that include them), that's not the case for Fortran modules. At least not today. Also, Flang's pre-processor is always run anyway (we only really "emulate" the split into pre and post-processing phases).
IIUC, this is consistent with your understanding - I want to make sure that we are on the same page and that I am not missing anything myself. If you agree with the above, then this PR is more about updating the definition of "pre-processed" Fortran files rather than e.g. fixing `-save-temps` or "*.i" files. It would be good to:
* Rephrase the summary to highlight that (e.g. "add pre-processing phase phase for Fortran pre-processed files").
* Add a comment in Types.def to explain the rationale behind ... having to pre-process files that have already been pre-processed.
How does it sound?
https://github.com/llvm/llvm-project/pull/104664
More information about the cfe-commits
mailing list