On Mon, Oct 20, 2014 at 8:26 AM, Aaron Ballman <[email protected]> wrote:
> On Sun, Oct 19, 2014 at 8:15 PM, Richard Smith > <[email protected]> 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?
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
