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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
