Commit Graph

11 Commits

Author SHA1 Message Date
Michael Kruse dc5ce72afa 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 01:21:16 +00:00
Akira Hatanaka 66d405d31f [Sema][ObjC] Do not propagate the nullability specifier on the receiver
to the result type of a message send if the result type cannot have a
nullability specifier.

Previously, clang would print the following message when the code in
nullability.m was compiled:

"incompatible integer to pointer conversion initializing 'int *' with
an expression of type 'int _Nullable'"

This is wrong as 'int' isn't supposed to have any nullability
specifiers.

rdar://problem/40830514

llvm-svn: 338048
2018-07-26 17:51:13 +00:00
Jordan Rose 303e2f1eac 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-10 23:28:17 +00:00
Akira Hatanaka 1b07496cea [Sema][ObjC] Compute the nullability of a conditional expression based
on the nullabilities of its operands.

This commit is a follow-up to r276076 and enables
computeConditionalNullability to compute the merged nullability when
the operands are objective-c pointers.

rdar://problem/22074116

llvm-svn: 276696
2016-07-25 21:58:19 +00:00
Douglas Gregor aea7afdc13 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-24 22:02:08 +00:00
Douglas Gregor 9d3430f355 Stop moving attributes off of a block literal's decl specifiers.
These usually apply to the return type. At one point this was necessary to
get some of them to apply to the entire block, but it appears that's working
anyway (see block-return.c).

rdar://problem/20468034

llvm-svn: 240189
2015-06-19 23:18:03 +00:00
Douglas Gregor 5c0870ac51 Handle 'instancetype' in ParseDeclarationSpecifiers.
...instead of as a special case in ParseObjCTypeName with lots of
duplicated logic. Besides being a nice refactoring, this also allows
"- (instancetype __nonnull)self" in addition to "- (nonnull instancetype)self".

rdar://problem/19924646

llvm-svn: 240188
2015-06-19 23:18:00 +00:00
Douglas Gregor 849ebc269f Implement the 'null_resettable' attribute for Objective-C properties.
'null_resettable' properties are those whose getters return nonnull
but whose setters take nil, to "reset" the property to some
default. Implements rdar://problem/19051334.

llvm-svn: 240155
2015-06-19 18:14:46 +00:00
Douglas Gregor 813a066f16 Extend type nullability qualifiers for Objective-C.
Introduce context-sensitive, non-underscored nullability specifiers
(nonnull, nullable, null_unspecified) for Objective-C method return
types, method parameter types, and properties.

Introduce Objective-C-specific semantics, including computation of the
nullability of the result of a message send, merging of nullability
information from the @interface of a class into its @implementation,
etc .

This is the Objective-C part of rdar://problem/18868820.

llvm-svn: 240154
2015-06-19 18:14:38 +00:00
Douglas Gregor b4866e85e5 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-19 18:13:19 +00:00
Douglas Gregor 261a89b0f7 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-19 17:51:05 +00:00