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/nullability.c

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

25 lines
792 B
C
Raw Normal View History

Introduce type nullability specifiers for C/C++. Introduces the type specifiers __nonnull, __nullable, and __null_unspecified that describe the nullability of the pointer type to which the specifier appertains. Nullability type specifiers improve on the existing nonnull attributes in a few ways: - They apply to types, so one can represent a pointer to a non-null pointer, use them in function pointer types, etc. - As type specifiers, they are syntactically more lightweight than __attribute__s or [[attribute]]s. - They can express both the notion of 'should never be null' and also 'it makes sense for this to be null', and therefore can more easily catch errors of omission where one forgot to annotate the nullability of a particular pointer (this will come in a subsequent patch). Nullability type specifiers are maintained as type sugar, and therefore have no effect on mangling, encoding, overloading, etc. Nonetheless, they will be used for warnings about, e.g., passing 'null' to a method that does not accept it. This is the C/C++ part of rdar://problem/18868820. llvm-svn: 240146
2015-06-20 01:51:05 +08:00
// RUN: %clang_cc1 -fsyntax-only -std=c99 -Wno-nullability-declspec -pedantic %s -verify
Replace __double_underscored type nullability qualifiers with _Uppercase_underscored Addresses a conflict with glibc's __nonnull macro by renaming the type nullability qualifiers as follows: __nonnull -> _Nonnull __nullable -> _Nullable __null_unspecified -> _Null_unspecified This is the major part of rdar://problem/21530726, but does not yet provide the Darwin-specific behavior for the old names. llvm-svn: 240596
2015-06-25 06:02:08 +08:00
_Nonnull int *ptr; // expected-warning{{type nullability specifier '_Nonnull' is a Clang extension}}
Introduce type nullability specifiers for C/C++. Introduces the type specifiers __nonnull, __nullable, and __null_unspecified that describe the nullability of the pointer type to which the specifier appertains. Nullability type specifiers improve on the existing nonnull attributes in a few ways: - They apply to types, so one can represent a pointer to a non-null pointer, use them in function pointer types, etc. - As type specifiers, they are syntactically more lightweight than __attribute__s or [[attribute]]s. - They can express both the notion of 'should never be null' and also 'it makes sense for this to be null', and therefore can more easily catch errors of omission where one forgot to annotate the nullability of a particular pointer (this will come in a subsequent patch). Nullability type specifiers are maintained as type sugar, and therefore have no effect on mangling, encoding, overloading, etc. Nonetheless, they will be used for warnings about, e.g., passing 'null' to a method that does not accept it. This is the C/C++ part of rdar://problem/18868820. llvm-svn: 240146
2015-06-20 01:51:05 +08:00
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wnullability-extension"
Replace __double_underscored type nullability qualifiers with _Uppercase_underscored Addresses a conflict with glibc's __nonnull macro by renaming the type nullability qualifiers as follows: __nonnull -> _Nonnull __nullable -> _Nullable __null_unspecified -> _Null_unspecified This is the major part of rdar://problem/21530726, but does not yet provide the Darwin-specific behavior for the old names. llvm-svn: 240596
2015-06-25 06:02:08 +08:00
_Nonnull int *ptr2; // no-warning
Introduce type nullability specifiers for C/C++. Introduces the type specifiers __nonnull, __nullable, and __null_unspecified that describe the nullability of the pointer type to which the specifier appertains. Nullability type specifiers improve on the existing nonnull attributes in a few ways: - They apply to types, so one can represent a pointer to a non-null pointer, use them in function pointer types, etc. - As type specifiers, they are syntactically more lightweight than __attribute__s or [[attribute]]s. - They can express both the notion of 'should never be null' and also 'it makes sense for this to be null', and therefore can more easily catch errors of omission where one forgot to annotate the nullability of a particular pointer (this will come in a subsequent patch). Nullability type specifiers are maintained as type sugar, and therefore have no effect on mangling, encoding, overloading, etc. Nonetheless, they will be used for warnings about, e.g., passing 'null' to a method that does not accept it. This is the C/C++ part of rdar://problem/18868820. llvm-svn: 240146
2015-06-20 01:51:05 +08:00
#pragma clang diagnostic pop
Fix a test case broken by my previous commit. llvm-svn: 240977
2015-06-30 02:15:31 +08:00
#if !__has_feature(nullability)
# error Nullability should always be supported
Introduce type nullability specifiers for C/C++. Introduces the type specifiers __nonnull, __nullable, and __null_unspecified that describe the nullability of the pointer type to which the specifier appertains. Nullability type specifiers improve on the existing nonnull attributes in a few ways: - They apply to types, so one can represent a pointer to a non-null pointer, use them in function pointer types, etc. - As type specifiers, they are syntactically more lightweight than __attribute__s or [[attribute]]s. - They can express both the notion of 'should never be null' and also 'it makes sense for this to be null', and therefore can more easily catch errors of omission where one forgot to annotate the nullability of a particular pointer (this will come in a subsequent patch). Nullability type specifiers are maintained as type sugar, and therefore have no effect on mangling, encoding, overloading, etc. Nonetheless, they will be used for warnings about, e.g., passing 'null' to a method that does not accept it. This is the C/C++ part of rdar://problem/18868820. llvm-svn: 240146
2015-06-20 01:51:05 +08:00
#endif
Accept nullability qualifiers on array parameters. Since array parameters decay to pointers, '_Nullable' and friends should be available for use there as well. This is especially important for parameters that are typedefs of arrays. The unsugared syntax for this follows the syntax for 'static'-sized arrays in C: void test(int values[_Nullable]); This syntax was previously accepted but the '_Nullable' (and any other attributes) were silently discarded. However, applying '_Nullable' to a typedef was previously rejected and is now accepted; therefore, it may be necessary to test for the presence of this feature: #if __has_feature(nullability_on_arrays) One important change here is that DecayedTypes don't always immediately contain PointerTypes anymore; they may contain an AttributedType instead. This only affected one place in-tree, so I would guess it's not likely to cause problems elsewhere. This commit does not change -Wnullability-completeness just yet. I want to think about whether it's worth doing something special to avoid breaking existing clients that compile with -Werror. It also doesn't change '#pragma clang assume_nonnull' behavior, which currently treats the following two declarations as equivalent: #pragma clang assume_nonnull begin void test(void *pointers[]); #pragma clang assume_nonnull end void test(void * _Nonnull pointers[]); This is not the desired behavior, but changing it would break backwards-compatibility. Most likely the best answer is going to be adding a new warning. Part of rdar://problem/25846421 llvm-svn: 286519
2016-11-11 07:28:17 +08:00
#if !__has_feature(nullability_on_arrays)
# error Nullability on array parameters should always be supported
#endif
Introduce type nullability specifiers for C/C++. Introduces the type specifiers __nonnull, __nullable, and __null_unspecified that describe the nullability of the pointer type to which the specifier appertains. Nullability type specifiers improve on the existing nonnull attributes in a few ways: - They apply to types, so one can represent a pointer to a non-null pointer, use them in function pointer types, etc. - As type specifiers, they are syntactically more lightweight than __attribute__s or [[attribute]]s. - They can express both the notion of 'should never be null' and also 'it makes sense for this to be null', and therefore can more easily catch errors of omission where one forgot to annotate the nullability of a particular pointer (this will come in a subsequent patch). Nullability type specifiers are maintained as type sugar, and therefore have no effect on mangling, encoding, overloading, etc. Nonetheless, they will be used for warnings about, e.g., passing 'null' to a method that does not accept it. This is the C/C++ part of rdar://problem/18868820. llvm-svn: 240146
2015-06-20 01:51:05 +08:00
#if !__has_extension(nullability)
# error Nullability should always be supported as an extension
#endif
Accept nullability qualifiers on array parameters. Since array parameters decay to pointers, '_Nullable' and friends should be available for use there as well. This is especially important for parameters that are typedefs of arrays. The unsugared syntax for this follows the syntax for 'static'-sized arrays in C: void test(int values[_Nullable]); This syntax was previously accepted but the '_Nullable' (and any other attributes) were silently discarded. However, applying '_Nullable' to a typedef was previously rejected and is now accepted; therefore, it may be necessary to test for the presence of this feature: #if __has_feature(nullability_on_arrays) One important change here is that DecayedTypes don't always immediately contain PointerTypes anymore; they may contain an AttributedType instead. This only affected one place in-tree, so I would guess it's not likely to cause problems elsewhere. This commit does not change -Wnullability-completeness just yet. I want to think about whether it's worth doing something special to avoid breaking existing clients that compile with -Werror. It also doesn't change '#pragma clang assume_nonnull' behavior, which currently treats the following two declarations as equivalent: #pragma clang assume_nonnull begin void test(void *pointers[]); #pragma clang assume_nonnull end void test(void * _Nonnull pointers[]); This is not the desired behavior, but changing it would break backwards-compatibility. Most likely the best answer is going to be adding a new warning. Part of rdar://problem/25846421 llvm-svn: 286519
2016-11-11 07:28:17 +08:00
#if !__has_extension(nullability_on_arrays)
# error Nullability on array parameters should always be supported as an extension
#endif