[cfe-dev] libclang clang_getCursorPlatformAvailability fails often

[Douglas Gregor]

Sent from my iPhone

On May 11, 2013, at 2:00 AM, ivan <ivasic+clang at gmail.com> wrote:

> Hi Doug,
> 
> I ran the preprocessor manually (clang -E vs. doing it from code), with
> similar flags it should be the same output I guess.
> 
> Anyway, seems you were right. There is a difference in how the compiler sees
> OSX and iOS APIs marked with NS_AVAILABLE. This is the original code in the
> header file:
> 
> - (NSComparisonResult)localizedStandardCompare:(NSString *)string
> NS_AVAILABLE(10_6, 4_0);
> 
> This is how it resolves for OSX:
> - (NSComparisonResult)localizedStandardCompare:(NSString *)string ;
> 
> And this is how it resolves for iOS:
> - (NSComparisonResult)localizedStandardCompare:(NSString *)string
> __attribute__((availability(ios,introduced=4.0)));
> 
> 
> It's clear now why clang_getCursorPlatformAvailability doesn't pick it up.
> Looking in the headers I found that NS_AVAILABLE is defined as
> __OSX_AVAILABLE_STARTING(__MAC_##_mac, __IPHONE_##_ios) on iOS targets and
> this macro always works (tried it in my own code). But if TARGET_OS_MAC is
> 1, the macro is defined as AVAILABLE_MAC_OS_X_VERSION_##_mac##_AND_LATER
> which never resolves into an __attribute__
> 
> Does this make sense? Not sure if this is a radar candidate or by design.

It's not by design; the headers just haven't been updated to match the compiler changes. It's worth a radar. 

> 
> 
> 
> 
> --
> View this message in context: http://clang-developers.42468.n3.nabble.com/libclang-clang-getCursorPlatformAvailability-fails-often-tp4032039p4032048.html
> Sent from the Clang Developers mailing list archive at Nabble.com.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev