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

57 lines
3.5 KiB
C
Raw Normal View History

Don't crash when trying to apply the availability attribute to a block. llvm-svn: 171899
2013-01-09 05:30:32 +08:00
// RUN: %clang_cc1 -triple x86_64-apple-darwin9 -fsyntax-only -fblocks -verify %s
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
availability in structured documents. Takes care of comments by Dimitri and Doug. llvm-svn: 164957
2012-10-02 02:42:25 +08:00
void f0() __attribute__((availability(macosx,introduced=10.4,deprecated=10.2))); // expected-warning{{feature cannot be deprecated in OS X version 10.2 before it was introduced in version 10.4; attribute ignored}}
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 f1() __attribute__((availability(ios,obsoleted=2.1,deprecated=3.0))); // expected-warning{{feature cannot be obsoleted in iOS version 2.1 before it was deprecated in version 3.0; attribute ignored}}
For the availability attribute, allow a declaration to be deprecated in the same version that it is introduced. Stuff happens. llvm-svn: 137214
2011-08-10 23:31:35 +08:00
void f2() __attribute__((availability(ios,introduced=2.1,deprecated=2.1)));
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
For the availability attribute, allow a declaration to be deprecated in the same version that it is introduced. Stuff happens. llvm-svn: 137214
2011-08-10 23:31:35 +08:00
void f3() __attribute__((availability(otheros,introduced=2.2))); // expected-warning{{unknown platform 'otheros' in availability macro}}
Add ability to supply additional message to availability macros, // rdar://10095131 llvm-svn: 146304
2011-12-10 08:28:41 +08:00
// rdar://10095131
extern void
Implemented delayed processing of 'unavailable' checking, just like with 'deprecated'. Fixes <rdar://problem/15584219> and <rdar://problem/12241361>. This change looks large, but all it does is reuse and consolidate the delayed diagnostic logic for deprecation warnings with unavailability warnings. By doing so, it showed various inconsistencies between the diagnostics, which were close, but not consistent. It also revealed some missing "note:"'s in the deprecated diagnostics that were showing up in the unavailable diagnostics, etc. This change also changes the wording of the core deprecation diagnostics. Instead of saying "function has been explicitly marked deprecated" we now saw "'X' has been been explicitly marked deprecated". It turns out providing a bit more context is useful, and often we got the actual term wrong or it was not very precise (e.g., "function" instead of "destructor"). By just saying the name of the thing that is deprecated/deleted/unavailable we define this issue away. This diagnostic can likely be further wordsmithed to be shorter. llvm-svn: 197627
2013-12-19 07:30:06 +08:00
ATSFontGetName(const char *oName) __attribute__((availability(macosx,introduced=8.0,deprecated=9.0, message="use CTFontCopyFullName"))); // expected-note {{'ATSFontGetName' has been explicitly marked deprecated here}}
Add ability to supply additional message to availability macros, // rdar://10095131 llvm-svn: 146304
2011-12-10 08:28:41 +08:00
extern void
Implemented delayed processing of 'unavailable' checking, just like with 'deprecated'. Fixes <rdar://problem/15584219> and <rdar://problem/12241361>. This change looks large, but all it does is reuse and consolidate the delayed diagnostic logic for deprecation warnings with unavailability warnings. By doing so, it showed various inconsistencies between the diagnostics, which were close, but not consistent. It also revealed some missing "note:"'s in the deprecated diagnostics that were showing up in the unavailable diagnostics, etc. This change also changes the wording of the core deprecation diagnostics. Instead of saying "function has been explicitly marked deprecated" we now saw "'X' has been been explicitly marked deprecated". It turns out providing a bit more context is useful, and often we got the actual term wrong or it was not very precise (e.g., "function" instead of "destructor"). By just saying the name of the thing that is deprecated/deleted/unavailable we define this issue away. This diagnostic can likely be further wordsmithed to be shorter. llvm-svn: 197627
2013-12-19 07:30:06 +08:00
ATSFontGetPostScriptName(int flags) __attribute__((availability(macosx,introduced=8.0,obsoleted=9.0, message="use ATSFontGetFullPostScriptName"))); // expected-note {{'ATSFontGetPostScriptName' has been explicitly marked unavailable here}}
Add ability to supply additional message to availability macros, // rdar://10095131 llvm-svn: 146304
2011-12-10 08:28:41 +08:00
void test_10095131() {
availability in structured documents. Takes care of comments by Dimitri and Doug. llvm-svn: 164957
2012-10-02 02:42:25 +08:00
ATSFontGetName("Hello"); // expected-warning {{'ATSFontGetName' is deprecated: first deprecated in OS X 9.0 - use CTFontCopyFullName}}
ATSFontGetPostScriptName(100); // expected-error {{'ATSFontGetPostScriptName' is unavailable: obsoleted in OS X 9.0 - use ATSFontGetFullPostScriptName}}
Add ability to supply additional message to availability macros, // rdar://10095131 llvm-svn: 146304
2011-12-10 08:28:41 +08:00
}
fixes location of "availability" attribute so warning is displayed at its line. // rdar://10711037 llvm-svn: 148747
2012-01-24 07:38:32 +08:00
// rdar://10711037
__attribute__((availability(macos, unavailable))) // expected-warning {{attribute 'availability' is ignored}}
enum {
NSDataWritingFileProtectionWriteOnly = 0x30000000,
NSDataWritingFileProtectionCompleteUntilUserAuthentication = 0x40000000,
};
Split mergeAvailabilityAttr out of handleAvailabilityAttr. This is important for having a uniform logic for adding attributes to a decl. This in turn is needed to fix the FIXME: // FIXME: This needs to happen before we merge declarations. Then, // let attribute merging cope with attribute conflicts. ProcessDeclAttributes(S, NewFD, D, /*NonInheritable=*/false, /*Inheritable=*/true); The idea is that mergeAvailabilityAttr will become a method. Once attributes are processed before merging, it will be called from handleAvailabilityAttr to handle multiple attributes in one decl: void f(int) __attribute__((availability(ios,deprecated=3.0), availability(ios,introduced=2.0))); and from SemaDecl.cpp to handle multiple decls: void f(int) __attribute__((availability(ios,deprecated=3.0))); void f(int) __attribute__((availability(ios,introduced=2.0))); As a bonus, use the new structure to diagnose incompatible availability attributes added to different decls (see included testcases). llvm-svn: 156269
2012-05-07 03:56:25 +08:00
void f4(int) __attribute__((availability(ios,deprecated=3.0)));
void f4(int) __attribute__((availability(ios,introduced=4.0))); // expected-warning {{feature cannot be deprecated in iOS version 3.0 before it was introduced in version 4.0; attribute ignored}}
Process attributes in the order they appear in the source code. This make clang match gcc behavior for two conflicting visibilities in the same decl. It also makes handling of dllimport/dllexport more natural. As a bonus we now warn on the dllimport in void __attribute__((dllimport)) foo13(); void __attribute__((dllexport)) foo13(); as does gcc. llvm-svn: 156343
2012-05-08 07:58:18 +08:00
void f5(int) __attribute__((availability(ios,deprecated=3.0),
availability(ios,introduced=4.0))); // expected-warning {{feature cannot be deprecated in iOS version 3.0 before it was introduced in version 4.0; attribute ignored}}
Split mergeAvailabilityAttr out of handleAvailabilityAttr. This is important for having a uniform logic for adding attributes to a decl. This in turn is needed to fix the FIXME: // FIXME: This needs to happen before we merge declarations. Then, // let attribute merging cope with attribute conflicts. ProcessDeclAttributes(S, NewFD, D, /*NonInheritable=*/false, /*Inheritable=*/true); The idea is that mergeAvailabilityAttr will become a method. Once attributes are processed before merging, it will be called from handleAvailabilityAttr to handle multiple attributes in one decl: void f(int) __attribute__((availability(ios,deprecated=3.0), availability(ios,introduced=2.0))); and from SemaDecl.cpp to handle multiple decls: void f(int) __attribute__((availability(ios,deprecated=3.0))); void f(int) __attribute__((availability(ios,introduced=2.0))); As a bonus, use the new structure to diagnose incompatible availability attributes added to different decls (see included testcases). llvm-svn: 156269
2012-05-07 03:56:25 +08:00
void f6(int) __attribute__((availability(ios,deprecated=3.0))); // expected-note {{previous attribute is here}}
void f6(int) __attribute__((availability(ios,deprecated=4.0))); // expected-warning {{availability does not match previous declaration}}
void f7(int) __attribute__((availability(ios,introduced=2.0)));
void f7(int) __attribute__((availability(ios,deprecated=3.0))); // expected-note {{previous attribute is here}}
void f7(int) __attribute__((availability(ios,deprecated=4.0))); // expected-warning {{availability does not match previous declaration}}
Add __has_feature(attribute_availability_with_message). This tests for the ability to include a "message" field in availability attributes, like so: extern void ATSFontGetName(const char *oName) __attribute__((availability(macosx,introduced=8.0,deprecated=9.0, message="use CTFontCopyFullName"))); This was actually supported in Clang 3.1, but we got a request for a __has_feature so that header files can use this more safely. It's unfortunate that the 3.1 release doesn't include this, however. <rdar://problem/11886458> llvm-svn: 160699
2012-07-25 05:55:34 +08:00
// <rdar://problem/11886458>
#if !__has_feature(attribute_availability_with_message)
# error "Missing __has_feature"
#endif
Clear the LV cache when merging the availability attribute. The availability implies default visibility, so it can change the computed visibility. llvm-svn: 171840
2013-01-08 12:04:30 +08:00
extern int x __attribute__((availability(macosx,introduced=10.5)));
extern int x;
Don't crash when trying to apply the availability attribute to a block. llvm-svn: 171899
2013-01-09 05:30:32 +08:00
void f8() {
int (^b)(int);
b = ^ (int i) __attribute__((availability(macosx,introduced=10.2))) { return 1; }; // expected-warning {{'availability' attribute ignored}}
}
Clear LV cache when dropping availability attributes. llvm-svn: 171906
2013-01-09 06:31:36 +08:00
extern int x2 __attribute__((availability(macosx,introduced=10.2))); // expected-note {{previous attribute is here}}
extern int x2 __attribute__((availability(macosx,introduced=10.5))); // expected-warning {{availability does not match previous declaration}}