maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Parser/attr-availability.c

33 lines
2.1 KiB
C
Raw Normal View History

Implement a new 'availability' attribute, that allows one to specify which versions of an OS provide a certain facility. For example, void foo() __attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6))); says that the function "foo" was introduced in 10.2, deprecated in 10.4, and completely obsoleted in 10.6. This attribute ties in with the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that we want to deploy back to Mac OS X 10.1). There are several concrete behaviors that this attribute enables, as illustrated with the function foo() above: - If we choose a deployment target >= Mac OS X 10.4, uses of "foo" will result in a deprecation warning, as if we had placed attribute((deprecated)) on it (but with a better diagnostic) - If we choose a deployment target >= Mac OS X 10.6, uses of "foo" will result in an "unavailable" warning (in C)/error (in C++), as if we had placed attribute((unavailable)) on it - If we choose a deployment target prior to 10.2, foo() is weak-imported (if it is a kind of entity that can be weak imported), as if we had placed the weak_import attribute on it. Naturally, there can be multiple availability attributes on a declaration, for different platforms; only the current platform matters when checking availability attributes. The only platforms this attribute currently works for are "ios" and "macosx", since we already have -mxxxx-version-min flags for them and we have experience there with macro tricks translating down to the deprecated/unavailable/weak_import attributes. The end goal is to open this up to other platforms, and even extension to other "platforms" that are really libraries (say, through a #pragma clang define_system), but that hasn't yet been designed and we may want to shake out more issues with this narrower problem first. Addresses <rdar://problem/6690412>. As a drive-by bug-fix, if an entity is both deprecated and unavailable, we only emit the "unavailable" diagnostic. llvm-svn: 128127
2011-03-23 08:50:03 +08:00
// RUN: %clang_cc1 -fsyntax-only -verify %s
Add a __has_feature check for the 'availability' attribute llvm-svn: 128337
2011-03-26 20:16:15 +08:00
#if !__has_feature(attribute_availability)
# error 'availability' attribute is not available
#endif
Implement a new 'availability' attribute, that allows one to specify which versions of an OS provide a certain facility. For example, void foo() __attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6))); says that the function "foo" was introduced in 10.2, deprecated in 10.4, and completely obsoleted in 10.6. This attribute ties in with the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that we want to deploy back to Mac OS X 10.1). There are several concrete behaviors that this attribute enables, as illustrated with the function foo() above: - If we choose a deployment target >= Mac OS X 10.4, uses of "foo" will result in a deprecation warning, as if we had placed attribute((deprecated)) on it (but with a better diagnostic) - If we choose a deployment target >= Mac OS X 10.6, uses of "foo" will result in an "unavailable" warning (in C)/error (in C++), as if we had placed attribute((unavailable)) on it - If we choose a deployment target prior to 10.2, foo() is weak-imported (if it is a kind of entity that can be weak imported), as if we had placed the weak_import attribute on it. Naturally, there can be multiple availability attributes on a declaration, for different platforms; only the current platform matters when checking availability attributes. The only platforms this attribute currently works for are "ios" and "macosx", since we already have -mxxxx-version-min flags for them and we have experience there with macro tricks translating down to the deprecated/unavailable/weak_import attributes. The end goal is to open this up to other platforms, and even extension to other "platforms" that are really libraries (say, through a #pragma clang define_system), but that hasn't yet been designed and we may want to shake out more issues with this narrower problem first. Addresses <rdar://problem/6690412>. As a drive-by bug-fix, if an entity is both deprecated and unavailable, we only emit the "unavailable" diagnostic. llvm-svn: 128127
2011-03-23 08:50:03 +08:00
void f0() __attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
void f1() __attribute__((availability(macosx,deprecated=10.4,introduced=10.2,obsoleted=10.6)));
void f2() __attribute__((availability(ios,deprecated=10.4.7,introduced=10,obsoleted=10.6)));
void f3() __attribute__((availability(ios,deprecated=10.4.7,introduced=10,obsoleted=10.6,introduced=10.2))); // expected-error{{redundant 'introduced' availability change; only the last specified change will be used}}
Extend the new 'availability' attribute with support for an 'unavailable' argument, which specifies that the declaration to which the attribute appertains is unavailable on that platform. llvm-svn: 128329
2011-03-26 11:35:55 +08:00
void f4() __attribute__((availability(macosx,introduced=10.5), availability(ios,unavailable)));
void f5() __attribute__((availability(macosx,introduced=10.5), availability(ios,unavailable, unavailable))); // expected-error{{redundant 'unavailable' availability change; only the last specified change will be used}}
Modify how the -verify flag works. Currently, the verification string and diagnostic message are compared. If either is a substring of the other, then no error is given. This gives rise to an unexpected case: // expect-error{{candidate function has different number of parameters}} will match the following error messages from Clang: candidate function has different number of parameters (expected 1 but has 2) candidate function has different number of parameters It will also match these other error messages: candidate function function has different number of parameters number of parameters This patch will change so that the verification string must be a substring of the diagnostic message before accepting. Also, all the failing tests from this change have been corrected. Some stats from this cleanup: 87 - removed extra spaces around verification strings 70 - wording updates to diagnostics 40 - extra leading or trailing characters (typos, unmatched parens or quotes) 35 - diagnostic level was included (error:, warning:, or note:) 18 - flag name put in the warning (-Wprotocol) llvm-svn: 146619
2011-12-15 08:38:15 +08:00
void f6() __attribute__((availability(macosx,unavailable,introduced=10.5))); // expected-warning{{'unavailable' availability overrides all other availability information}}
Extend the new 'availability' attribute with support for an 'unavailable' argument, which specifies that the declaration to which the attribute appertains is unavailable on that platform. llvm-svn: 128329
2011-03-26 11:35:55 +08:00
As Aaron pointed out it's simpler to reject wide string availability attr messages in the parser. llvm-svn: 190706
2013-09-14 01:31:48 +08:00
void f7() __attribute__((availability(macosx,message=L"wide"))); // expected-error {{expected string literal for optional message in 'availability' attribute}}
Parse: Diagnose malformed 'message' arguments for 'availability' attr The parsing code for 'availability' wasn't prepared for string literals like "a" L"b" showing up. Error if this occurs. llvm-svn: 213350
2014-07-18 13:43:12 +08:00
void f8() __attribute__((availability(macosx,message="a" L"b"))); // expected-error {{expected string literal for optional message in 'availability' attribute}}
Add ability to supply additional message to availability macros, // rdar://10095131 llvm-svn: 146304
2011-12-10 08:28:41 +08:00
// rdar://10095131
enum E{
Made the "expected string literal" diagnostic more expressive llvm-svn: 168267
2012-11-18 03:16:52 +08:00
gorf __attribute__((availability(macosx,introduced=8.5, message = 10.0))), // expected-error {{expected string literal for optional message in 'availability' attribute}}
Add ability to supply additional message to availability macros, // rdar://10095131 llvm-svn: 146304
2011-12-10 08:28:41 +08:00
garf __attribute__((availability(macosx,introduced=8.5, message))), // expected-error {{expected '=' after 'message'}}
foo __attribute__((availability(macosx,introduced=8.5,deprecated=9.0, message="Use CTFontCopyPostScriptName()", deprecated=10.0))) // expected-error {{expected ')'}} \
// expected-note {{to match this '('}}
};