r220177 - [modules] Add support for #include_next.

[Richard Smith]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141020/8ba4b7b9/attachment.html>