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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

41 lines
2.8 KiB
C
Raw Normal View History

[NFC] Add -std=c11 to attr-availability.c This test will fail with any toolchains that don't default to C11. Adding this switch to the clang invocation in the test fixes the issue. Patch by Justice Adams! Reviewed By: dyung Differential Revision: https://reviews.llvm.org/D94829
2021-01-16 13:02:26 +08:00
// RUN: %clang_cc1 -std=c11 -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
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the fourth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-08 04:28:35 +08:00
void f0(void) __attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
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
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the fourth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-08 04:28:35 +08:00
void f1(void) __attribute__((availability(macosx,deprecated=10.4,introduced=10.2,obsoleted=10.6)));
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
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the fourth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-08 04:28:35 +08:00
void f2(void) __attribute__((availability(ios,deprecated=10.4.7,introduced=10,obsoleted=10.6)));
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
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the fourth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-08 04:28:35 +08:00
void f3(void) __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}}
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
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the fourth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-08 04:28:35 +08:00
void f4(void) __attribute__((availability(macosx,introduced=10.5), availability(ios,unavailable)));
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
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the fourth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-08 04:28:35 +08:00
void f5(void) __attribute__((availability(macosx,introduced=10.5), availability(ios,unavailable, unavailable))); // expected-error{{redundant 'unavailable' 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
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the fourth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-08 04:28:35 +08:00
void f6(void) __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
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the fourth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-08 04:28:35 +08:00
void f7(void) __attribute__((availability(macosx,message=L"wide"))); // expected-error {{expected string literal for optional message in 'availability' attribute}}
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
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the fourth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-08 04:28:35 +08:00
void f8(void) __attribute__((availability(macosx,message="a" L"b"))); // 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
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the fourth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-08 04:28:35 +08:00
void f9(void) __attribute__((availability(macosx,message=u8"b"))); // expected-error {{expected string literal for optional message in 'availability' attribute}}
Fix inconsistent availability attribute message string literal check. Function Parser::ParseAvailabilityAttribute checks that the message string of an availability attribute is not a wide string literal. Test case clang/test/Parser/attr-availability.c specifies that a string literal is expected. The code checked that the first token in a string concatenation is a string literal, and then that the concatenated string consists of 1-byte characters. On a target where wide character is 1 byte, a string concatenation "a" L"b" passes both those checks, but L"b" alone is rejected. More generally, "a" u8"b" passes the checks, but u8"b" alone is rejected. So check isAscii() instead of character size.
2020-12-09 01:33:59 +08:00
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the fourth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-08 04:28:35 +08:00
void f10(void) __attribute__((availability(macosx,message="a" u8"b"))); // expected-error {{expected string literal for optional message in 'availability' attribute}}
Fix inconsistent availability attribute message string literal check. Function Parser::ParseAvailabilityAttribute checks that the message string of an availability attribute is not a wide string literal. Test case clang/test/Parser/attr-availability.c specifies that a string literal is expected. The code checked that the first token in a string concatenation is a string literal, and then that the concatenated string consists of 1-byte characters. On a target where wide character is 1 byte, a string concatenation "a" L"b" passes both those checks, but L"b" alone is rejected. More generally, "a" u8"b" passes the checks, but u8"b" alone is rejected. So check isAscii() instead of character size.
2020-12-09 01:33:59 +08:00
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the fourth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-08 04:28:35 +08:00
void f11(void) __attribute__((availability(macosx,message=u"b"))); // expected-error {{expected string literal for optional message in 'availability' attribute}}
Fix inconsistent availability attribute message string literal check. Function Parser::ParseAvailabilityAttribute checks that the message string of an availability attribute is not a wide string literal. Test case clang/test/Parser/attr-availability.c specifies that a string literal is expected. The code checked that the first token in a string concatenation is a string literal, and then that the concatenated string consists of 1-byte characters. On a target where wide character is 1 byte, a string concatenation "a" L"b" passes both those checks, but L"b" alone is rejected. More generally, "a" u8"b" passes the checks, but u8"b" alone is rejected. So check isAscii() instead of character size.
2020-12-09 01:33:59 +08:00
Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the fourth batch of tests being updated (there are a significant number of other tests left to be updated).
2022-02-08 04:28:35 +08:00
void f12(void) __attribute__((availability(macosx,message="a" u"b"))); // expected-error {{expected string literal for optional message in 'availability' attribute}}
Fix inconsistent availability attribute message string literal check. Function Parser::ParseAvailabilityAttribute checks that the message string of an availability attribute is not a wide string literal. Test case clang/test/Parser/attr-availability.c specifies that a string literal is expected. The code checked that the first token in a string concatenation is a string literal, and then that the concatenated string consists of 1-byte characters. On a target where wide character is 1 byte, a string concatenation "a" L"b" passes both those checks, but L"b" alone is rejected. More generally, "a" u8"b" passes the checks, but u8"b" alone is rejected. So check isAscii() instead of character size.
2020-12-09 01:33:59 +08:00
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 '('}}
};