r220177 - [modules] Add support for #include_next.

[Aaron Ballman]

On Mon, Oct 20, 2014 at 7:21 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Mon, Oct 20, 2014 at 4:16 PM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
>>
>> 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).
>
>
> That's circular; our own stdint.h uses __UINT_* to define those types.

My point is that it doesn't have to -- those can be defined entirely
using standard fundamental types. However, I would agree that using
the fundamental types could make this file considerably more messy,
and this is information the compiler already has on hand.

>
>>
>> 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?
>
>
> Well, we ship such a system header with Clang, so yes. But we can also
> change that header if we think that's a better alternative.

As I said, this is a weak preference of mine (and a few folks seem to
have a strong preference for unconditionally providing those macros),
so I'm fine with going the direction the majority wishes for. I do not
see any incompatibility worries we may run into with MSVC today --
they currently define everything in terms of fundamental types. Do we
have to worry about a future MSVC version providing their own macros
with equivalent functionality, but different names?

~Aaron