r220177 - [modules] Add support for #include_next.

[Reid Kleckner]

FTR I agree with this approach, I don't see why we should treat these
macros specially.

On Tue, Oct 21, 2014 at 12:35 PM, Aaron Ballman <aaron at aaronballman.com>
wrote:

> On Tue, Oct 21, 2014 at 11:31 AM, JF Bastien <jfb at chromium.org> wrote:
> >> The compiler has documented sizes for fundamental types which can be
> >> used to define the types in this file. Eg)
> >>
> >> typedef signed char        int8_t;
> >> typedef short              int16_t;
> >> typedef int                int32_t;
> >>
> >> Nothing says we cannot provide this in similar fashion for our
> >> stdint.h; though, as I pointed out, that could make this file *very*
> >> ugly with a bunch of target-specific #ifs everywhere to ensure the
> >> proper definitions of *int*_t and friends. I can understand not
> >> wanting to do that (especially since the compiler already has this
> >> information internally).
> >
> >
> > The compiler guaranteeing something is different from that guarantee
> being
> > in the language. C and C++ standard libraries like newlib target multiple
> > compilers and can't rely on what LLVM guarantees, so they either have to
> use
> > configure and ask the compiler by compiling a program, or just straight
> up
> > ask the compiler when it provides nice macros.
>
> Since others seem to be strongly in favor of (2), I will favor it as
> well. I have made commit r220312 which implements (2), and brings the
> MSVC compat bots back to being green.
>
> ~Aaron
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141021/05a04259/attachment.html>