[clang] Reland: Instantiate alias templates with sugar (#101858)

This makes use of the changes introduced in D134604, in order to
instantiate alias templates witn a final sugared substitution.

T

[clang] Reland: Instantiate alias templates with sugar (#101858)

This makes use of the changes introduced in D134604, in order to
instantiate alias templates witn a final sugared substitution.

This comes at no additional relevant cost.
Since we don't track / unique them in specializations, we wouldn't be
able to resugar them later anyway.

Differential Revision: https://reviews.llvm.org/D136565

show more ...

Reapply "[clang][nullability] allow _Nonnull etc on nullable class types (#82705)" (#87325)

This reverts commit 28760b63bbf9e267713957105a8d17091fb0d20e.

The last commit was missing the new testc

Reapply "[clang][nullability] allow _Nonnull etc on nullable class types (#82705)" (#87325)

This reverts commit 28760b63bbf9e267713957105a8d17091fb0d20e.

The last commit was missing the new testcase, now fixed.

show more ...

Revert "Reapply "[clang][nullability] allow _Nonnull etc on nullable class types (#82705)"" (#87041)

This reverts commit bbbcc1d99d08855069f4501c896c43a6d4d7b598.

This change is causing the follo

Revert "Reapply "[clang][nullability] allow _Nonnull etc on nullable class types (#82705)"" (#87041)

This reverts commit bbbcc1d99d08855069f4501c896c43a6d4d7b598.

This change is causing the following build bots to fail due to a missing
header file:
- https://lab.llvm.org/buildbot/#/builders/188/builds/43765
- https://lab.llvm.org/buildbot/#/builders/176/builds/9428
- https://lab.llvm.org/buildbot/#/builders/187/builds/14696
- https://lab.llvm.org/buildbot/#/builders/186/builds/15551
- https://lab.llvm.org/buildbot/#/builders/182/builds/9413
- https://lab.llvm.org/buildbot/#/builders/245/builds/22507
- https://lab.llvm.org/buildbot/#/builders/258/builds/16026
- https://lab.llvm.org/buildbot/#/builders/249/builds/17221
- https://lab.llvm.org/buildbot/#/builders/38/builds/18566
- https://lab.llvm.org/buildbot/#/builders/214/builds/11735
- https://lab.llvm.org/buildbot/#/builders/231/builds/21947
- https://lab.llvm.org/buildbot/#/builders/230/builds/26675
- https://lab.llvm.org/buildbot/#/builders/57/builds/33922
- https://lab.llvm.org/buildbot/#/builders/124/builds/10311
- https://lab.llvm.org/buildbot/#/builders/109/builds/86173
- https://lab.llvm.org/buildbot/#/builders/280/builds/1043
- https://lab.llvm.org/buildbot/#/builders/283/builds/440
- https://lab.llvm.org/buildbot/#/builders/247/builds/16034
- https://lab.llvm.org/buildbot/#/builders/139/builds/62423
- https://lab.llvm.org/buildbot/#/builders/216/builds/36718
- https://lab.llvm.org/buildbot/#/builders/259/builds/2039
- https://lab.llvm.org/buildbot/#/builders/36/builds/44091
- https://lab.llvm.org/buildbot/#/builders/272/builds/12629
- https://lab.llvm.org/buildbot/#/builders/271/builds/6020
- https://lab.llvm.org/buildbot/#/builders/236/builds/10319

show more ...

Reapply "[clang][nullability] allow _Nonnull etc on nullable class types (#82705)"

This reverts commit ca4c4a6758d184f209cb5d88ef42ecc011b11642.

This was intended not to introduce new consistency d

Reapply "[clang][nullability] allow _Nonnull etc on nullable class types (#82705)"

This reverts commit ca4c4a6758d184f209cb5d88ef42ecc011b11642.

This was intended not to introduce new consistency diagnostics for
smart pointer types, but failed to ignore sugar around types when
detecting this.
Fixed and test added.

show more ...

Revert "[clang][nullability] allow _Nonnull etc on nullable class types (#82705)"

This reverts commit 92a09c0165b87032e1bd05020a78ed845cf35661.

This is triggering a bunch of new -Wnullability-compl

Revert "[clang][nullability] allow _Nonnull etc on nullable class types (#82705)"

This reverts commit 92a09c0165b87032e1bd05020a78ed845cf35661.

This is triggering a bunch of new -Wnullability-completeness warnings
in code with existing raw pointer nullability annotations.

The intent was the new nullability locations wouldn't affect those
warnings, so this is a bug at least for now.

show more ...

[clang][nullability] allow _Nonnull etc on nullable class types (#82705)

This enables clang and external nullability checkers to make use of
these annotations on nullable C++ class types like unique

[clang][nullability] allow _Nonnull etc on nullable class types (#82705)

This enables clang and external nullability checkers to make use of
these annotations on nullable C++ class types like unique_ptr.

These types are recognized by the presence of the _Nullable attribute.
Nullable standard library types implicitly receive this attribute.

Existing static warnings for raw pointers are extended to smart
pointers:

- nullptr used as return value or argument for non-null functions
(`-Wnonnull`)
- assigning or initializing nonnull variables with nullable values
(`-Wnullable-to-nonnull-conversion`)

It doesn't implicitly add these attributes based on the assume_nonnull
pragma, nor warn on missing attributes where the pragma would apply
them.
I'm not confident that the pragma's current behavior will work well for
C++ (where type-based metaprogramming is much more common than C/ObjC).
We'd like to revisit this once we have more implementation experience.

Support can be detected as `__has_feature(nullability_on_classes)`.
This is needed for back-compatibility, as previously clang would issue a
hard error when _Nullable appears on a smart pointer.

UBSan's `-fsanitize=nullability` will not check smart-pointer types.
It can be made to do so by synthesizing calls to `operator bool`, but
that's left for future work.

Discussion:
https://discourse.llvm.org/t/rfc-allowing-nonnull-etc-on-smart-pointers/77201/26

show more ...

[Clang] Fix unconditional access to Attr pointer when checking if _Nullable is applicable to a type

In TransformAttributedType(...) when checking if _Nullable can be applied to a
type it dereference

[Clang] Fix unconditional access to Attr pointer when checking if _Nullable is applicable to a type

In TransformAttributedType(...) when checking if _Nullable can be applied to a
type it dereferences TL.getAttr() unconditionally which we can see from the code
earlier in the function is not correct since it is expected to be nullptr in
some cases.

It looks like the correct course of action is to use TL.getModifiedLoc() over
TL.getAttr()->getLocation() in the case that TL.getAttr() returns a nullptr.

Fixes: https://github.com/llvm/llvm-project/issues/60344

Differential Revision: https://reviews.llvm.org/D142799

show more ...

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 Ha

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).

show more ...

Revert "Compress formatting of array type names (int [4] -> int[4])"

Looks like lldb has some issues with this - somehow it causes lldb to
treat a "char[N]" type as an array of chars (prints them ou

Revert "Compress formatting of array type names (int [4] -> int[4])"

Looks like lldb has some issues with this - somehow it causes lldb to
treat a "char[N]" type as an array of chars (prints them out
individually) but a "char [N]" is printed as a string. (even though the
DWARF doesn't have this string in it - it's something to do with the
string lldb generates for itself using clang)

This reverts commit 277623f4d5a672d707390e2c3eaf30a9eb4b075c.

show more ...

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 HasEmptyPlac

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).

show more ...

Print nullptr_t namespace qualified within std::

This improves diagnostic (& important to me, DWARF) accuracy - otherwise
there could be ambiguities between "std::nullptr_t" and some user-defined
ty

Print nullptr_t namespace qualified within std::

This improves diagnostic (& important to me, DWARF) accuracy - otherwise
there could be ambiguities between "std::nullptr_t" and some user-defined
type that's /actually/ "nullptr_t" defined in the global namespace.

Differential Revision: https://reviews.llvm.org/D110044

show more ...

Do not issue -Wnullability-completeness for dependent types that are not written as pointer types.

llvm-svn: 303451

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 param

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

show more ...

[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 enab

[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

show more ...

[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

[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

show more ...

Make __has_feature(nullability) and __has_extension(nullability) always true.

These are _Underbar_capital-prefixed additions to the language that
shouldn't depend on language standard.

llvm-svn: 24

Make __has_feature(nullability) and __has_extension(nullability) always true.

These are _Underbar_capital-prefixed additions to the language that
shouldn't depend on language standard.

llvm-svn: 240976

show more ...

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:

__no

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

show more ...

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, us

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

show more ...

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

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

show more ...