No, I think I'm just a bit more dense today than usual. I blame it on the weather. ;-)
I tried: #define __has_attribute(x) 0 #if __has_attribute([[clang::fallthrough]]) sdfsdfsfsd #endif #if __has_attribute(__attribute__((weakref))) dsfdfsdf #endif #if __has_attribute(__declspec(dllexport)) sdfsdf #endif This compiles without errors or warnings in MSVC 2013, 2012 and 2010. Same for gcc 4.8.1. Great question (once I understood it), btw! ~Aaron On Sat, Jan 11, 2014 at 3:02 PM, Alp Toker <[email protected]> wrote: > > On 11/01/2014 19:41, Aaron Ballman wrote: >> >> On Sat, Jan 11, 2014 at 2:31 PM, Alp Toker <[email protected]> wrote: >>> >>> On 10/01/2014 22:07, Aaron Ballman wrote: >>>> >>>> The __has_attribute feature macro is fantastic in many respects, but >>>> is lacking the ability to determine whether a specific attribute >>>> syntax is available or not. Instead, it currently checks whether the >>>> attribute is known within the compilation target, and nothing more. >>>> This can cause problems because not all attributes are applied in the >>>> same way. >>>> >>>> Consider dllexport as a contrived example: >>>> >>>> #if __has_attribute(dllexport) >>>> void foo(void) __attribute__((dllexport)); >>>> #endif >>>> >>>> This code looks fine, but is actually broken because clang only >>>> supports __declspec(dllexport) and not __attribute__((dllexport)), and >>>> __declspec must precede the declaration. >>>> >>>> The attached patch implements new syntax for __has_attribute while >>>> retaining backwards compatibility. It allows you to specify exactly >>>> which attribute syntax you desire. If no specific syntax is specified, >>>> it behaves as it always has. >>>> >>>> The supported forms are: >>>> >>>> __has_attribute(__attribute__((ident))) // GNU-style >>>> __has_attribute(__declspec(ident)) // MS-style >>>> __has_attribute([[ident]]) // C++11-style >>>> __has_attribute([[scope::ident]]) // C++11-style >>>> __has_attribute(ident) // Keywords, or "don't care" >>>> >>>> Note that attribute arguments are not supported by design -- they >>>> really don't make any sense in the context of a feature macro. >>> >>> >>> Hi Aaron, >>> >>> This is a step forward with some long-standing problems so certainly >>> would >>> be a step forward. The syntax is unconventional but not unreasonable. >>> >>> Have you confirmed that the new __has_attribute() syntax can still be >>> defined to an empty expansion? That pattern is important to provide >>> source >>> compatibility with gcc / MSVC. The latter in particular has fairly >>> different >>> expansion rules to watch out for -- I've got a feeling it'll be OK as >>> long >>> as no commas appear in the argument list (which was a problem with the >>> other >>> proposed "cxx, ..." syntax) but it's worth double checking. >> >> There's currently a test in the test suite which I think covers this case: >> >> // CHECK: has_has_attribute >> #ifdef __has_attribute >> int has_has_attribute(); >> #endif >> >> Is that what you are referring to? If so, then yes, this patch does >> still meet that need. > > > Sorry, I wasn't particularly clear :-) > > The ifdef/undef ability for __has_attribute in clang itself is clearly > fine.. > > I was referring rather to the compatibility, in practice, of the following > pattern (as seen in LLVM's Compiler.h): > > #ifndef __has_attribute > # define __has_attribute(x) 0 > #endif > > This would potentially have been a problem with syntax (2) proposed by > Richard Smith in PR15853 given that commas are macro argument delimiters, > and compounded by the fact that Microsoft has a different take on variadic > macros. That would have made it difficult or impossible to provide an empty > macro definition fallback for non-clang compilers. > > What I'm wondering is whether your proposed __has_attribute syntax has any > similar expansion problems, taking into account the kinds of arguments it > accepts. > > I'm hopeful that there won't be a problem because you've already > intentionally excluded attribute arguments from the syntax, therefore commas > can't appear -- but it's still worth checking this to see if the various > attribute token sequences work in practice with third-party preprocessors. > > Alp. > > > >> Thanks! >> >> ~Aaron > > > -- > http://www.nuanti.com > the browser experts > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
