[libcxx-dev] Why does libcxx include its own files this way?

Duncan Exon Smith via libcxx-dev libcxx-dev at lists.llvm.org
Fri Jan 18 10:05:50 PST 2019


+libcxx-dev, which got dropped
+Bruno

> On 2019 Jan  18, at 07:21, Olivier Giroux <OGiroux at nvidia.com> wrote:
> 
> But you agree that it does, though, right?

Hmm.  To be concrete, this is what I was worried about:

#!/bin/bash

run() { echo "$*" >&2; "$@" || exit 1; }
run mkdir -p quote
run cat </dev/null >quote/type_traits
run /usr/bin/printf "%s\n" \
    "#include <vector>" \
    "std::vector<int> g;" \
    > t.cpp
run clang -iquote quote -fsyntax-only t.cpp

which should give this output:

$ bash t.sh 
mkdir -p quote
cat
/usr/bin/printf %s\n #include <vector> std::vector<int> g;
clang -iquote quote -fsyntax-only t.cpp

(i.e., no errors)

I thought if we switched to quoted "type_traits" everywhere I'd see a spew of errors.  However, I'd forgotten that quoted includes check relative to the includer *first*, before hitting the search paths.  So I was wrong here and this testcase doesn't expose a problem with your suggestion.

One other concern I have is that the funny #include_next dance between libc++ headers, clang headers, and libc (especially on Darwin-derived SDKs) continues work for modules.  I kind of doubt your idea would cause a problem there since libc++ should be the outer most layer, but it's pretty subtle and I'd want to be sure.  Bruno might be able to check that out for you if you make a patch.

Bruno, are there other concerns for modules as well?

>  
> That’s actually a problem that I spend a bunch of time working around in my CUDA standard library port. I don’t want to interfere with <atomic> so I make <cuda/atomic> but then that header wants to include <type_traits> instead of the <cuda/type_traits> that I need it to find. If it included "type_traits" instead, it would all just work.
>  
> So I have work-arounds for that, and obviously I can also flip <> to "" in my fork, but do you want to see ""?
>  
> Makes sense?
>  
> Olivier
>  
> From: <dexonsmith at apple.com> on behalf of Duncan Exon Smith <dexonsmith at apple.com>
> Date: Friday, January 18, 2019 at 5:46 AM
> To: Olivier Giroux <OGiroux at nvidia.com>
> Cc: Libc++ Dev <libcxx-dev at lists.llvm.org>
> Subject: Re: [libcxx-dev] Why does libcxx include its own files this way?
>  
> I don’t think we want Libc++ to pick up files in -iquote search paths. 
> 
> On Jan 17, 2019, at 22:20, Olivier Giroux via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
> 
>> Inside of libcxx, you can see #include <name> being used when the library is _clearly_ intending for it to find the file that #include "name" would find. I say it’s clear because, if any other file in the world were chosen, then the library would likely fail to compile.
>>  
>> It looks to me like the use of #include <name> is an attempt to enforce a reservation on this name in the filesystem of the build machine. If true, then it’s kind of an overreach. I’d personally much rather if these sideways includes used #include "name" instead.
>>  
>> Is there a better explanation for why this is done this way?
>>  
>> Olivier
>>  
>> This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
>> _______________________________________________
>> libcxx-dev mailing list
>> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190118/c6855f46/attachment-0001.html>


More information about the libcxx-dev mailing list