[PATCH] D121588: [C++20][Modules][Driver][HU 1/N] Initial handling for -xc++-{system,user}-header.

[Iain Sandoe via Phabricator via cfe-commits]

iains added inline comments.


================
Comment at: clang/test/Driver/cxx20-header-units-01.cpp:7
+
+// RUN: %clang++ -### -std=c++20 -xc++-header-unit-header %S/Inputs/header-unit-01.hh 2>&1 | \
+// RUN:   FileCheck -check-prefix=CHECK-ABS %s -DTDIR=%S/Inputs
----------------
vsapsai wrote:
> iains wrote:
> > vsapsai wrote:
> > > What should happen in case of inconsistencies like `%clang++ -### -std=c++20 -xc++-system-header %S/Inputs/header-unit-01.hh`? Or `-xc++-system-header foo.h`?
> > If the user states that `%S/Inputs/header-unit-01.hh` is a system header, I do not think that the driver is in a position to argue?
> > 
> > `  -xc++-system-header foo.h `  again the user has made an explicit statement..
> > 
> > I suppose that we can always diagnose these things with warnings - but I do not think we can easily reject them (and we risk producing unhelpful output).
> What is the intended use of `-xc++-user-header` and `-xc++-system-header`? Are these supposed to be commonly-used flags or as an escape hatch of some sort? Because if it is commonly-used, I have concerns about usability that forces users to track user and system headers correctly, and duplicates the information already encoded in header search paths.
> 
> Also I think it is out of scope but for usability it is important to know the consequences of using a wrong flag and how one can diagnose it. Have no idea what you've already planned in this area, just mentioning it because I'm scarred by inscrutable clang behavior.
These are "generally internal" marking to be specific about how files should be treated.

The usual user-facing commands would be `-fmodule-header={user, system}`

So the answer is no, they would not be commonly used - pretty much the same as `-x c++` or so, only necessary if the file type is ambiguous to the driver in some way.

If the user wants a specific header to be searched for in the user or system paths, then it is reasonable that they have to indicate this.  Actually, probably the largest benefit is that the user would not need to know where system headers were stored -- so when trying to build a header unit for, say, 'vector' it would greatly simplify the process,

I hope that the behaviour should not be in any way inscrutable - there are some things that the user (or build system) has to communicate to the driver, it cannot deduce them (and where to search for headers is in that category).

----

the consequences of using the wrong flag in this case would be a failure to find the header file (the diagnostic would be emitted by the FE rather than the driver, but that would be transparent to a regular user).   The logic here is that using the lookup paths is not a job for the driver, because the FE already knows and has mechanisms for it.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121588/new/

https://reviews.llvm.org/D121588