[cfe-dev] libclang clang_getCursorPlatformAvailability fails often

ivan ivasic+clang at gmail.com
Sat May 11 02:00:46 PDT 2013


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.






--
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.



More information about the cfe-dev mailing list