r220177 - [modules] Add support for #include_next.

[Aaron Ballman]

Like I said, it's a weak preference. ;-) However, "it makes it easier
to do nonstandard things" isn't really a ringing endorsement for
making this change be consistent with GCC in my book. At the end of
the day, there's int8_t and uint8_t definitions, which do the standard
thing, and don't require messes (that I'm aware of).

When this discussion comes up about supporting nonstandard things from
MSVC, the usual watermark is: are there system headers we can't
compile without this change?

~Aaron

On Mon, Oct 20, 2014 at 7:08 PM, JF Bastien <jfb at chromium.org> wrote:
> r211657 made it easier to support newlib, makes the interface clang provides
> more uniform (there are already similar macros), and more compatible with
> GCC. I'd argue they're standard macros because of their naming :-)
>
> On Mon, Oct 20, 2014 at 4:03 PM, Joerg Sonnenberger
> <joerg at britannica.bec.de> wrote:
>>
>> On Mon, Oct 20, 2014 at 07:02:01PM -0400, Aaron Ballman wrote:
>> > 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.
>>
>> Supporting char vs unsigned char gets messy without out.
>>
>> Joerg
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>