r220177 - [modules] Add support for #include_next.

[Aaron Ballman]

On Mon, Oct 20, 2014 at 5:51 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Mon, Oct 20, 2014 at 8:26 AM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
>>
>> On Sun, Oct 19, 2014 at 8:15 PM, Richard Smith
>> <richard-llvm at metafoo.co.uk> wrote:
>> > Author: rsmith
>> > Date: Sun Oct 19 19:15:49 2014
>> > New Revision: 220177
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=220177&view=rev
>> > Log:
>> > [modules] Add support for #include_next.
>> >
>> > #include_next interacts poorly with modules: it depends on where in the
>> > list of
>> > include paths the current file was found. Files covered by module maps
>> > are not
>> > found in include search paths when building the module (and are not
>> > found in
>> > include search paths when @importing the module either), so this isn't
>> > really
>> > meaningful. Instead, we fake up the result that #include_next *should*
>> > have
>> > given: find the first path that would have resulted in the given file
>> > being
>> > picked, and search from there onwards.
>> >
>> > Added:
>> >     cfe/trunk/test/Modules/Inputs/include_next/
>> >     cfe/trunk/test/Modules/Inputs/include_next/x/
>> >     cfe/trunk/test/Modules/Inputs/include_next/x/a.h
>> >     cfe/trunk/test/Modules/Inputs/include_next/x/module.modulemap
>> >     cfe/trunk/test/Modules/Inputs/include_next/x/subdir/
>> >     cfe/trunk/test/Modules/Inputs/include_next/x/subdir/b.h
>> >     cfe/trunk/test/Modules/Inputs/include_next/y/
>> >     cfe/trunk/test/Modules/Inputs/include_next/y/a.h
>> >     cfe/trunk/test/Modules/Inputs/include_next/y/b.h
>> >     cfe/trunk/test/Modules/Inputs/include_next/y/module.modulemap
>> >     cfe/trunk/test/Modules/include_next.c
>> > Modified:
>> >     cfe/trunk/docs/Modules.rst
>> >     cfe/trunk/include/clang/Lex/Preprocessor.h
>> >     cfe/trunk/lib/Frontend/VerifyDiagnosticConsumer.cpp
>> >     cfe/trunk/lib/Lex/ModuleMap.cpp
>> >     cfe/trunk/lib/Lex/PPDirectives.cpp
>> >     cfe/trunk/lib/Lex/PPMacroExpansion.cpp
>> >     cfe/trunk/lib/Lex/Pragma.cpp
>> >     cfe/trunk/test/Modules/cstd.m
>>
>> This commit is causing test failures for me locally. My output (Win 7,
>> MSVC x86 debug build of clang) is:
>>
>> >lit E:\llvm\llvm\tools\clang\test\Modules\cstd.m
>> -- Testing: 1 tests, 1 threads --
>> FAIL: Clang :: Modules/cstd.m (1 of 1)
>> ******************** TEST 'Clang :: Modules/cstd.m' FAILED
>> ********************
>> Script:
>> --
>> rm -rf E:\llvm\2013\tools\clang\test\Modules\Output\cstd.m.tmp
>> E:/llvm/2013/Debug/bin/clang.EXE  -fsyntax-only -isystem
>> E:\llvm\llvm\tools\clang\test\Modules/Inputs/System/usr/include
>> -ffreestanding -fmodules
>>
>> -fmodules-cache-path=E:\llvm\2013\tools\clang\test\Modules\Output\cstd.m.tmp
>> -D__need_wint_t -Werror=implicit-function-declaration
>> E:\llvm\llvm\tools\clang\test\Modules\cstd.m
>> --
>> Exit Code: 1
>>
>> Command Output (stdout):
>> --
>> Command 0: "rm" "-rf"
>> "E:\llvm\2013\tools\clang\test\Modules\Output\cstd.m.tmp"
>> Command 0 Result: 0
>> Command 0 Output:
>>
>>
>> Command 0 Stderr:
>>
>>
>> Command 1: "E:/llvm/2013/Debug/bin/clang.EXE" "-fsyntax-only"
>> "-isystem"
>> "E:\llvm\llvm\tools\clang\test\Modules/Inputs/System/usr/include"
>> "-ffreestanding" "-fmodules"
>>
>> "-fmodules-cache-path=E:\llvm\2013\tools\clang\test\Modules\Output\cstd.m.tmp"
>> "-D__need_wint_t" "-Werror=implicit-function-declaration"
>> "E:\llvm\llvm\tools\clang\test\Modules\cstd.m"
>> Command 1 Result: 1
>> Command 1 Output:
>>
>>
>> Command 1 Stderr:
>> While building module 'uses_other_constants' imported from
>> E:\llvm\llvm\tools\clang\test\Modules\cstd.m:4:
>>
>> While building module 'cstd' imported from
>>
>> E:\llvm\llvm\tools\clang\test\Modules/Inputs/System/usr/include\uses_other_constants.h:2:
>>
>> In file included from <module-includes>:5:
>>
>> E:\llvm\2013\Debug\bin\..\lib\clang\3.6.0\include\stdint.h:109:9:
>> error: unknown type name '__UINT64_TYPE__'
>>
>> typedef __UINT64_TYPE__ uint64_t;
>>
>>         ^
>
>
> r211657 (http://reviews.llvm.org/D4141) added the __UINTn_TYPE__ macros,
> strictly for GCC compatibility, excluding them from MSVC mode since we have
> no need to be GCC-compatible there.
> r214119
> (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140714/110254.html)
> then switched stdint.h to use these macros in all modes where we don't have
> a system stdint.h or are freestanding.
>
> So, this was technically a regression for MSVC -ffreestanding mode
> introduced by r214119. The question is, how to fix? Either:
>
> 1) Partial revert of r214119 to not use these __UINT_* macros (that is, we
> decide that we only have them for GCC compatibility), or
> 2) Remove MSVCCompat checks from r211657 (that is, we decide that the macros
> are a guaranteed part of Clang's interface too), or
> 3) Provide the macros in MSVCCompat mode only if we're freestanding.
>
> I'm opposed to (3), but mention it here for completeness. Thoughts?

I have a very slight preference for (1) over (2) -- I don't see the
benefit to guaranteeing those nonstandard macros as being part of
Clang's interface.

~Aaron