r220177 - [modules] Add support for #include_next.
aaron at aaronballman.com
Mon Oct 20 16:16:21 PDT 2014
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?
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.
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
More information about the cfe-commits