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

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

250 lines
13 KiB
C
Raw Normal View History

Diagnose unsafe uses of nil and __nonnull pointers. This generalizes the checking of null arguments to also work with values of pointer-to-function, reference-to-function, and block pointer type, using the nullability information within the underling function prototype to extend non-null checking, and diagnoses returns of 'nil' within a function with a __nonnull return type. Note that we don't warn about nil returns from Objective-C methods, because it's common for Objective-C methods to mimic the nil-swallowing behavior of the receiver by checking ostensibly non-null parameters and returning nil from otherwise non-null methods in that case. It also diagnoses (via a separate flag) conversions from nullable to nonnull pointers. It's a separate flag because this warning can be noisy. llvm-svn: 240153
2015-06-20 02:13:19 +08:00
// RUN: %clang_cc1 -fsyntax-only -fblocks -Wnullable-to-nonnull-conversion -Wno-nullability-declspec %s -verify
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_feature(nullability)
#else
# error nullability feature should be defined
#endif
typedef int * int_ptr;
// Parse nullability type specifiers.
Set the default C standard to C99 when targeting the PS4. Patch by Douglas Yung! Differential Revision: http://reviews.llvm.org/D19003 llvm-svn: 267772
2016-04-28 03:53:03 +08:00
// This note requires C11.
#if __STDC_VERSION__ > 199901L
// expected-note@+2{{'_Nonnull' specified here}}
#endif
typedef int * _Nonnull nonnull_int_ptr;
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
typedef int * _Nullable nullable_int_ptr;
typedef int * _Null_unspecified null_unspecified_int_ptr;
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
// Redundant nullability type specifiers.
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
typedef int * _Nonnull _Nonnull redundant_1; // expected-warning{{duplicate nullability specifier '_Nonnull'}}
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
// Conflicting nullability type specifiers.
Append new attributes to the end of an AttributeList. Recommit of r335084 after revert in r335516. ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse order, and therefore printed in the wrong order in -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effect, especially on diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attributes' order was changed instead. This unfortunately causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible to each other. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reverse. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 338800
2018-08-03 09:21:16 +08:00
typedef int * _Nonnull _Nullable conflicting_1; // expected-error{{nullability specifier '_Nullable' conflicts with existing specifier '_Nonnull'}}
typedef int * _Null_unspecified _Nonnull conflicting_2; // expected-error{{nullability specifier '_Nonnull' conflicts with existing specifier '_Null_unspecified'}}
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
// Redundant nullability specifiers via a typedef are okay.
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
typedef nonnull_int_ptr _Nonnull redundant_okay_1;
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
// Conflicting nullability specifiers via a typedef are not.
Set the default C standard to C99 when targeting the PS4. Patch by Douglas Yung! Differential Revision: http://reviews.llvm.org/D19003 llvm-svn: 267772
2016-04-28 03:53:03 +08:00
// Some of these errors require C11.
#if __STDC_VERSION__ > 199901L
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
typedef nonnull_int_ptr _Nullable conflicting_2; // expected-error{{nullability specifier '_Nullable' conflicts with existing specifier '_Nonnull'}}
Set the default C standard to C99 when targeting the PS4. Patch by Douglas Yung! Differential Revision: http://reviews.llvm.org/D19003 llvm-svn: 267772
2016-04-28 03:53:03 +08:00
#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
typedef nonnull_int_ptr nonnull_int_ptr_typedef;
Set the default C standard to C99 when targeting the PS4. Patch by Douglas Yung! Differential Revision: http://reviews.llvm.org/D19003 llvm-svn: 267772
2016-04-28 03:53:03 +08:00
#if __STDC_VERSION__ > 199901L
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
typedef nonnull_int_ptr_typedef _Nullable conflicting_2; // expected-error{{nullability specifier '_Nullable' conflicts with existing specifier '_Nonnull'}}
Set the default C standard to C99 when targeting the PS4. Patch by Douglas Yung! Differential Revision: http://reviews.llvm.org/D19003 llvm-svn: 267772
2016-04-28 03:53:03 +08:00
#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
typedef nonnull_int_ptr_typedef nonnull_int_ptr_typedef_typedef;
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
typedef nonnull_int_ptr_typedef_typedef _Null_unspecified conflicting_3; // expected-error{{nullability specifier '_Null_unspecified' conflicts with existing specifier '_Nonnull'}}
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
// Nullability applies to all pointer types.
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
typedef int (* _Nonnull function_pointer_type_1)(int, int);
typedef int (^ _Nonnull block_type_1)(int, int);
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
// Nullability must be on a pointer type.
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
typedef int _Nonnull int_type_1; // expected-error{{nullability specifier '_Nonnull' cannot be applied to non-pointer type 'int'}}
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
// Nullability can move out to a pointer/block pointer declarator
// (with a suppressed warning).
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
typedef _Nonnull int * nonnull_int_ptr_2;
typedef int _Nullable * nullable_int_ptr_2;
typedef _Nonnull int (* function_pointer_type_2)(int, int);
typedef _Nonnull int (^ block_type_2)(int, int);
typedef _Nonnull int * * _Nullable nonnull_int_ptr_ptr_1;
typedef _Nonnull int *(^ block_type_3)(int, int);
typedef _Nonnull int *(* function_pointer_type_3)(int, int);
typedef _Nonnull int_ptr (^ block_type_4)(int, int);
typedef _Nonnull int_ptr (* function_pointer_type_4)(int, int);
PR10405 - Desugar FunctionType and TemplateSpecializationType if any type that appears inside needs to be desugared. llvm-svn: 242371
2015-07-16 09:06:17 +08:00
typedef void (* function_pointer_type_5)(int_ptr _Nonnull);
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
void acceptFunctionPtr(_Nonnull int *(*)(void));
void acceptBlockPtr(_Nonnull int *(^)(void));
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
void testBlockFunctionPtrNullability() {
float *fp;
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
fp = (function_pointer_type_3)0; // expected-warning{{from 'function_pointer_type_3' (aka 'int * _Nonnull (*)(int, int)')}}
fp = (block_type_3)0; // expected-error{{from incompatible type 'block_type_3' (aka 'int * _Nonnull (^)(int, int)')}}
PR10405 - Desugar FunctionType and TemplateSpecializationType if any type that appears inside needs to be desugared. llvm-svn: 242371
2015-07-16 09:06:17 +08:00
fp = (function_pointer_type_4)0; // expected-warning{{from 'function_pointer_type_4' (aka 'int * _Nonnull (*)(int, int)')}}
fp = (function_pointer_type_5)0; // expected-warning{{from 'function_pointer_type_5' (aka 'void (*)(int * _Nonnull)')}}
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
fp = (block_type_4)0; // expected-error{{from incompatible type 'block_type_4' (aka 'int_ptr _Nonnull (^)(int, int)')}}
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
acceptFunctionPtr(0); // no-warning
acceptBlockPtr(0); // no-warning
}
// Moving nullability where it creates a conflict.
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
typedef _Nonnull int * _Nullable * conflict_int_ptr_ptr_2; // expected-error{{nullability specifier '_Nonnull' cannot be applied to non-pointer type 'int'}}
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
// Nullability is not part of the canonical type.
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
typedef int * _Nonnull ambiguous_int_ptr;
Set the default C standard to C99 when targeting the PS4. Patch by Douglas Yung! Differential Revision: http://reviews.llvm.org/D19003 llvm-svn: 267772
2016-04-28 03:53:03 +08:00
// Redefining a typedef is a C11 feature.
#if __STDC_VERSION__ > 199901L
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
typedef int * ambiguous_int_ptr;
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
typedef int * _Nullable ambiguous_int_ptr;
Set the default C standard to C99 when targeting the PS4. Patch by Douglas Yung! Differential Revision: http://reviews.llvm.org/D19003 llvm-svn: 267772
2016-04-28 03:53:03 +08:00
#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
// Printing of nullability.
float f;
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
int * _Nonnull ip_1 = &f; // expected-warning{{incompatible pointer types initializing 'int * _Nonnull' with an expression of type 'float *'}}
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
// Check printing of nullability specifiers.
void printing_nullability(void) {
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
int * _Nonnull iptr;
float *fptr = iptr; // expected-warning{{incompatible pointer types initializing 'float *' with an expression of type 'int * _Nonnull'}}
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
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
int * * _Nonnull iptrptr;
float **fptrptr = iptrptr; // expected-warning{{incompatible pointer types initializing 'float **' with an expression of type 'int ** _Nonnull'}}
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
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
int * _Nullable * _Nonnull iptrptr2;
float * *fptrptr2 = iptrptr2; // expected-warning{{incompatible pointer types initializing 'float **' with an expression of type 'int * _Nullable * _Nonnull'}}
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
}
Diagnose unsafe uses of nil and __nonnull pointers. This generalizes the checking of null arguments to also work with values of pointer-to-function, reference-to-function, and block pointer type, using the nullability information within the underling function prototype to extend non-null checking, and diagnoses returns of 'nil' within a function with a __nonnull return type. Note that we don't warn about nil returns from Objective-C methods, because it's common for Objective-C methods to mimic the nil-swallowing behavior of the receiver by checking ostensibly non-null parameters and returning nil from otherwise non-null methods in that case. It also diagnoses (via a separate flag) conversions from nullable to nonnull pointers. It's a separate flag because this warning can be noisy. llvm-svn: 240153
2015-06-20 02:13:19 +08:00
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
// Check passing null to a _Nonnull argument.
void accepts_nonnull_1(_Nonnull int *ptr);
void (*accepts_nonnull_2)(_Nonnull int *ptr);
void (^accepts_nonnull_3)(_Nonnull int *ptr);
Diagnose unsafe uses of nil and __nonnull pointers. This generalizes the checking of null arguments to also work with values of pointer-to-function, reference-to-function, and block pointer type, using the nullability information within the underling function prototype to extend non-null checking, and diagnoses returns of 'nil' within a function with a __nonnull return type. Note that we don't warn about nil returns from Objective-C methods, because it's common for Objective-C methods to mimic the nil-swallowing behavior of the receiver by checking ostensibly non-null parameters and returning nil from otherwise non-null methods in that case. It also diagnoses (via a separate flag) conversions from nullable to nonnull pointers. It's a separate flag because this warning can be noisy. llvm-svn: 240153
2015-06-20 02:13:19 +08:00
void test_accepts_nonnull_null_pointer_literal() {
accepts_nonnull_1(0); // expected-warning{{null passed to a callee that requires a non-null argument}}
accepts_nonnull_2(0); // expected-warning{{null passed to a callee that requires a non-null argument}}
accepts_nonnull_3(0); // expected-warning{{null passed to a callee that requires a non-null argument}}
}
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
// Check returning nil from a _Nonnull-returning function.
_Nonnull int *returns_int_ptr(int x) {
Diagnose unsafe uses of nil and __nonnull pointers. This generalizes the checking of null arguments to also work with values of pointer-to-function, reference-to-function, and block pointer type, using the nullability information within the underling function prototype to extend non-null checking, and diagnoses returns of 'nil' within a function with a __nonnull return type. Note that we don't warn about nil returns from Objective-C methods, because it's common for Objective-C methods to mimic the nil-swallowing behavior of the receiver by checking ostensibly non-null parameters and returning nil from otherwise non-null methods in that case. It also diagnoses (via a separate flag) conversions from nullable to nonnull pointers. It's a separate flag because this warning can be noisy. llvm-svn: 240153
2015-06-20 02:13:19 +08:00
if (x) {
return 0; // expected-warning{{null returned from function that requires a non-null return value}}
}
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
return (_Nonnull int *)0;
Diagnose unsafe uses of nil and __nonnull pointers. This generalizes the checking of null arguments to also work with values of pointer-to-function, reference-to-function, and block pointer type, using the nullability information within the underling function prototype to extend non-null checking, and diagnoses returns of 'nil' within a function with a __nonnull return type. Note that we don't warn about nil returns from Objective-C methods, because it's common for Objective-C methods to mimic the nil-swallowing behavior of the receiver by checking ostensibly non-null parameters and returning nil from otherwise non-null methods in that case. It also diagnoses (via a separate flag) conversions from nullable to nonnull pointers. It's a separate flag because this warning can be noisy. llvm-svn: 240153
2015-06-20 02:13:19 +08:00
}
// Check nullable-to-nonnull conversions.
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
void nullable_to_nonnull(_Nullable int *ptr) {
Diagnose unsafe uses of nil and __nonnull pointers. This generalizes the checking of null arguments to also work with values of pointer-to-function, reference-to-function, and block pointer type, using the nullability information within the underling function prototype to extend non-null checking, and diagnoses returns of 'nil' within a function with a __nonnull return type. Note that we don't warn about nil returns from Objective-C methods, because it's common for Objective-C methods to mimic the nil-swallowing behavior of the receiver by checking ostensibly non-null parameters and returning nil from otherwise non-null methods in that case. It also diagnoses (via a separate flag) conversions from nullable to nonnull pointers. It's a separate flag because this warning can be noisy. llvm-svn: 240153
2015-06-20 02:13:19 +08:00
int *a = ptr; // okay
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 *b = ptr; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
[Sema] Make nullness warnings appear in C++. Given the following code: int *_Nullable ptr; int *_Nonnull nn = ptr; ...In C, clang will warn you about `nn = ptr`, because you're assigning a nonnull pointer to a nullable pointer. In C++, clang issues no such warning. This patch helps ensure that clang doesn't ever miss an opportunity to complain about C++ code. N.B. Though this patch has a differential revision link, the actual review took place over email. Differential Revision: http://reviews.llvm.org/D14938 llvm-svn: 255556
2015-12-15 06:00:49 +08:00
b = ptr; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
accepts_nonnull_1(ptr); // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
Diagnose unsafe uses of nil and __nonnull pointers. This generalizes the checking of null arguments to also work with values of pointer-to-function, reference-to-function, and block pointer type, using the nullability information within the underling function prototype to extend non-null checking, and diagnoses returns of 'nil' within a function with a __nonnull return type. Note that we don't warn about nil returns from Objective-C methods, because it's common for Objective-C methods to mimic the nil-swallowing behavior of the receiver by checking ostensibly non-null parameters and returning nil from otherwise non-null methods in that case. It also diagnoses (via a separate flag) conversions from nullable to nonnull pointers. It's a separate flag because this warning can be noisy. llvm-svn: 240153
2015-06-20 02:13:19 +08:00
}
[Sema] Compute the nullability of a conditional expression based on the nullabilities of its operands. This patch defines a function to compute the nullability of conditional expressions, which enables Sema to precisely detect implicit conversions of nullable conditional expressions to nonnull pointers. rdar://problem/25166556 Differential Revision: https://reviews.llvm.org/D22392 llvm-svn: 276076
2016-07-20 09:48:11 +08:00
// Check nullability of conditional expressions.
void conditional_expr(int c) {
int * _Nonnull p;
int * _Nonnull nonnullP;
int * _Nullable nullableP;
int * _Null_unspecified unspecifiedP;
int *noneP;
p = c ? nonnullP : nonnullP;
p = c ? nonnullP : nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
p = c ? nonnullP : unspecifiedP;
p = c ? nonnullP : noneP;
p = c ? nullableP : nonnullP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
p = c ? nullableP : nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
p = c ? nullableP : unspecifiedP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
p = c ? nullableP : noneP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
p = c ? unspecifiedP : nonnullP;
p = c ? unspecifiedP : nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
p = c ? unspecifiedP : unspecifiedP;
p = c ? unspecifiedP : noneP;
p = c ? noneP : nonnullP;
p = c ? noneP : nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
p = c ? noneP : unspecifiedP;
p = c ? noneP : noneP;
// Check that we don't remove all sugar when creating a new QualType for the
// conditional expression.
typedef int *IntP;
typedef IntP _Nonnull NonnullIntP0;
typedef NonnullIntP0 _Nonnull NonnullIntP1;
typedef IntP _Nullable NullableIntP0;
typedef NullableIntP0 _Nullable NullableIntP1;
NonnullIntP1 nonnullP2;
NullableIntP1 nullableP2;
p = c ? nonnullP2 : nonnullP2;
p = c ? nonnullP2 : nullableP2; // expected-warning{{implicit conversion from nullable pointer 'IntP _Nullable' (aka 'int *') to non-nullable pointer type 'int * _Nonnull'}}
p = c ? nullableP2 : nonnullP2; // expected-warning{{implicit conversion from nullable pointer 'NullableIntP1' (aka 'int *') to non-nullable pointer type 'int * _Nonnull'}}
p = c ? nullableP2 : nullableP2; // expected-warning{{implicit conversion from nullable pointer 'NullableIntP1' (aka 'int *') to non-nullable pointer type 'int * _Nonnull'}}
}
// Check nullability of binary conditional expressions.
void binary_conditional_expr() {
int * _Nonnull p;
int * _Nonnull nonnullP;
int * _Nullable nullableP;
int * _Null_unspecified unspecifiedP;
int *noneP;
p = nonnullP ?: nonnullP;
p = nonnullP ?: nullableP;
p = nonnullP ?: unspecifiedP;
p = nonnullP ?: noneP;
p = nullableP ?: nonnullP;
p = nullableP ?: nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
p = nullableP ?: unspecifiedP;
p = nullableP ?: noneP;
p = unspecifiedP ?: nonnullP;
p = unspecifiedP ?: nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
p = unspecifiedP ?: unspecifiedP;
p = unspecifiedP ?: noneP;
p = noneP ?: nonnullP;
p = noneP ?: nullableP; // expected-warning{{implicit conversion from nullable pointer 'int * _Nullable' to non-nullable pointer type 'int * _Nonnull'}}
p = noneP ?: unspecifiedP;
p = noneP ?: noneP;
}
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
extern int GLOBAL_LENGTH;
// Nullability can appear on arrays when the arrays are in parameter lists.
void arrays(int ints[_Nonnull],
void *ptrs[_Nullable],
void **nestedPtrs[_Nullable],
void * _Null_unspecified * _Nonnull nestedPtrs2[_Nullable],
int fixedSize[_Nonnull 2],
int staticSize[_Nonnull static 2],
int staticSize2[static _Nonnull 2],
int starSize[_Nonnull *],
int vla[_Nonnull GLOBAL_LENGTH],
void ** _Nullable reference);
void testDecayedType() {
int produceAnErrorMessage = arrays; // expected-warning {{incompatible pointer to integer conversion initializing 'int' with an expression of type 'void (int * _Nonnull, void ** _Nullable, void *** _Nullable, void * _Null_unspecified * _Nonnull * _Nullable, int * _Nonnull, int * _Nonnull, int * _Nonnull, int * _Nonnull, int * _Nonnull, void ** _Nullable)'}}
}
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-15 05:52:47 +08:00
int notInFunction[_Nullable 3]; // expected-error {{nullability specifier '_Nullable' cannot be applied to non-pointer type 'int[3]'}}
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
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-15 05:52:47 +08:00
void nestedArrays(int x[5][_Nonnull 1]) {} // expected-error {{nullability specifier '_Nonnull' cannot be applied to non-pointer type 'int[1]'}}
void nestedArrays2(int x[5][_Nonnull 1][2]) {} // expected-error {{nullability specifier '_Nonnull' cannot be applied to non-pointer type 'int[1][2]'}}
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
void nestedArraysOK(int x[_Nonnull 5][1]) {} // ok
void nullabilityOnBase(_Nonnull int x[1], // expected-error {{nullability specifier '_Nonnull' cannot be applied to non-pointer type 'int'}}
int _Nonnull y[1]); // expected-error {{nullability specifier '_Nonnull' cannot be applied to non-pointer type 'int'}}
typedef int INTS[4];
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-15 05:52:47 +08:00
typedef int BAD_INTS[_Nonnull 4]; // expected-error {{nullability specifier '_Nonnull' cannot be applied to non-pointer type 'int[4]'}}
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
void typedefTest(INTS _Nonnull x,
_Nonnull INTS xx,
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-15 05:52:47 +08:00
INTS _Nonnull y[2], // expected-error {{nullability specifier '_Nonnull' cannot be applied to non-pointer type 'INTS' (aka 'int[4]')}}
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
INTS z[_Nonnull 2]);
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-15 05:52:47 +08:00
INTS _Nonnull x; // expected-error {{nullability specifier '_Nonnull' cannot be applied to non-pointer type 'INTS' (aka 'int[4]')}}
_Nonnull INTS x; // expected-error {{nullability specifier '_Nonnull' cannot be applied to non-pointer type 'INTS' (aka 'int[4]')}}
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
void arraysInBlocks() {
typedef int INTS[4];
void (^simple)(int [_Nonnull 2]) = ^(int x[_Nonnull 2]) {};
simple(0); // expected-warning {{null passed to a callee that requires a non-null argument}}
void (^nested)(void *_Nullable x[_Nonnull 2]) = ^(void *_Nullable x[_Nonnull 2]) {};
nested(0); // expected-warning {{null passed to a callee that requires a non-null argument}}
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-15 05:52:47 +08:00
void (^nestedBad)(int x[2][_Nonnull 2]) = // expected-error {{nullability specifier '_Nonnull' cannot be applied to non-pointer type 'int[2]'}}
^(int x[2][_Nonnull 2]) {}; // expected-error {{nullability specifier '_Nonnull' cannot be applied to non-pointer type 'int[2]'}}
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
void (^withTypedef)(INTS _Nonnull) = ^(INTS _Nonnull x) {};
withTypedef(0); // expected-warning {{null passed to a callee that requires a non-null argument}}
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-15 05:52:47 +08:00
void (^withTypedefBad)(INTS _Nonnull [2]) = // expected-error {{nullability specifier '_Nonnull' cannot be applied to non-pointer type 'INTS' (aka 'int[4]')}}
^(INTS _Nonnull x[2]) {}; // expected-error {{nullability specifier '_Nonnull' cannot be applied to non-pointer type 'INTS' (aka 'int[4]')}}
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
}