r197995 - Don't reserve __builtin_types_compatible_p as a C++ keyword

Alp Toker alp at nuanti.com
Tue Dec 24 20:06:20 PST 2013


On 25/12/2013 03:26, Chandler Carruth wrote:
> I really don't have any idea what you're saying here. This sounds like 
> you are alluding a really significant new feature / functionality / 
> design for Clang's compiler-provided diagnostics

There's no major change. My view is that the current scheme is fine with 
some tweaking, while Richard Smith had the idea to handle these as 
context-sensitive keywords instead of language keywords. So those are 
two possible ways it might go.

Both are low-impact but would offer a way to diagnose on this 
consistently with other keywords disabled based on the language standard.

Forcibly enabling type traits in all language modes where they don't 
apply is the wrong way to do this and will get in the way of providing 
__has_feature() for new type traits which the libc++ guys have requested 
recently.

So yes, there is a driving feature.

> , and I've not seen anything that lay out the design you have in mind 
> (your vague comments here don't help, sorry). Maybe I've just missed 
> it over the holiday season and you can point me to the thread or 
> proposal you've sent out that outlines the end state you're working 
> toward?

The discussions are under the "type trait" thread a couple of weeks ago 
if you want to catch up.

>
> Can you actually address my concern? If you agree with my stance, then 
> why is this the right incremental step? I don't see how this makes 
> anything better, and it has the potential to make Clang less strict 
> and informative than it used to be.

It's not right to enable the keyword as a C++ type trait, which was an 
oversight in my original type trait rework that I've just got around to 
fixing.

If you think it's a significant feature to retain a special diagnostic 
when  __builtin_types_compatible_p is used in C++ mode, it needs to be 
done a different way.

So if this diagnostic was important to you, the options are either to 
wait until a more general compatibility warning is in place, or if you 
need this urgently we can add it back a non-type-trait dead keyword or 
poisoned identifier.

Out of curiousity, is this something you've actually needed? All 
evidence points to it being a leftover from 2007-2008 when 
language-specific traits weren't possible.

Alp.

-- 
http://www.nuanti.com
the browser experts




More information about the cfe-commits mailing list