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