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