On Mon, Oct 20, 2014 at 5:51 PM, Richard Smith <[email protected]> wrote: > 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?
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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
