r212060 - Consider module depedencies when checking a preamble in libclang
Ben Langmuir
blangmuir at apple.com
Mon Jul 7 10:03:33 PDT 2014
> On Jul 7, 2014, at 9:27 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote:
>
> Ben Langmuir <blangmuir at apple.com> wrote on 07.07.2014 18:12:21:
>
>>> And indeed running clang directly against the temporary files created
> by
>>> the test case I get:
>>> uweigand at bns:~> ./llvm/build/llvm-head-debug/Debug+Asserts/bin/clang
>>> -fmodules
> -I /tmp/libclang-test-6a8ede /tmp/libclang-test-6a8ede/MFile.m
>>> /tmp/libclang-test-6a8ede/MFile.m:2:25: error: variable has incomplete
> type
>>> 'struct Foo'
>>> int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
>>> ^
>>> /tmp/libclang-test-6a8ede/MFile.m:2:21: note: forward declaration of
>>> 'struct Foo'
>>> int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
>>> ^
>>> 1 error generated.
>>
>> Could you try this again with the additional flags -Wmodule-build -
>> Wauto-import as a sanity check that the module is being found? It
>> looks like the module isn’t being imported properly...
>
> Hmm, interesting. I get:
>
> uweigand at bns:~> ./llvm/build/llvm-head-debug/Debug+Asserts/bin/clang
> -fmodules -I /tmp/libclang-test-75f2f2 /tmp/libclang-test-75f2f2/MFile.m
> -Wmodule-build -Wauto-import
> /tmp/libclang-test-75f2f2/MFile.m:1:1: warning: treating #include as an
> import of module 'A' [-Wauto-import]
> #include "HeaderFile.h"
> ^~~~~~~~~~~~~~~~~~~~~~~
> @import A;
> /tmp/libclang-test-75f2f2/MFile.m:1:2: remark: building module 'A' as
> '/var/tmp/org.llvm.clang/ModuleCache/1MXAFKYV64X0T/A-25ZFQ1VWL2WP7.pcm' [-Rmodule-build]
>
> #include "HeaderFile.h"
> ^
> /tmp/libclang-test-75f2f2/MFile.m:2:25: error: variable has incomplete type
> 'struct Foo'
> int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
> ^
> /tmp/libclang-test-75f2f2/MFile.m:2:21: note: forward declaration of
> 'struct Foo'
> int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
> ^
> 1 warning and 1 error generated.
>
> However, the really interesting fact is that afterwards,
> there is no /var/tmp/org.llvm.clang/ModuleCache/1MXAFKYV64X0T
> directory -- and there cannot be, because there is a
> /var/tmp/org.llvm.clang/ModuleCache directory, owned
> by another user on the system, and my user ID does not
> have the privileges to create subdirectories there ...
>
>
> After I've removed that directory, the test case now passes!
> (But it will presumably fail for other users now …)
>
> How is this supposed to work on a multi-user machine?
I’ll fix the test to specify a unique module cache path. In general, we use llvm::sys::path::system_temp_dir to create the default module cache location. On Darwin, we use DARWIN_USER_CACHE_DIR, which is user-specific so this isn’t an issue. On Linux, we seem to honour the environment variable TMPDIR, before falling back to /var/tmp. I don’t know if this is correct for Linux; perhaps you know of a better way?
Ben
>
> Bye,
> Ulrich
More information about the cfe-commits
mailing list