On Jul 26, 2013, at 3:50 PM, Jonathan Schleifer <[email protected]> wrote:
> Am 27.07.2013 um 00:44 schrieb John McCall:
>> I feel like making your runtime's unit tests more portable across compiler
>> versions isn’t really a compelling reason to expose something like this
>> that’s essentially a fix to an existing language feature. We don’t get to
>> remove __has_feature checks ever, so we’ve generally tried to avoid them for
>> improvements like this, because otherwise the logic produces a plausible
>> argument for basically every change to the compiler to get an independent
>> __has_feature check.
>
> It's not only for the tests, this was just an example. It's basically the
> only way to check if forwarding for stret is safe. Without a way to check it,
> the whole feature is useless, because then you can never use it, as you have
> to expect that it crashes because an old Clang version or GCC could be used.
The feature enables users to rely on arbitrary message forwarding if they're
willing to live on certain minimum compiler and runtime versions. That’s a
pretty simple and comprehensible message for users.
In fact, if I remember correctly, we didn’t actually support generating code
correctly for your runtime until fairly recently, so your users are all
perfectly aware of the concept of a minimum compiler version.
I really doubt that your users are going to write preprocessor-conditionalized
code so that they can figure out whether they’re running on the one single
compiler + runtime configuration that supports a major restructuring of their
code to rely on arbitrary message forwarding.
The policy of clang is not to introduce __has_feature checks for bug fixes.
John.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
