[clang] Enable C++11-style attributes in all language modes

This also ignores and deprecates the `-fdouble-square-bracket-attributes` command line flag, which seems to not be used anywhere. At least

[clang] Enable C++11-style attributes in all language modes

This also ignores and deprecates the `-fdouble-square-bracket-attributes` command line flag, which seems to not be used anywhere. At least a code search exclusively found mentions of it in documentation: https://sourcegraph.com/search?q=context:global+-fdouble-square-bracket-attributes+-file:clang/*+-file:test/Sema/*+-file:test/Parser/*+-file:test/AST/*+-file:test/Preprocessor/*+-file:test/Misc/*+archived:yes&patternType=standard&sm=0&groupBy=repo

RFC: https://discourse.llvm.org/t/rfc-enable-c-11-c2x-attributes-in-all-standard-modes-as-an-extension-and-remove-fdouble-square-bracket-attributes

This enables `[[]]` attributes in all C and C++ language modes without warning by default. `-Wc++-extensions` does warn. GCC has enabled this extension in all C modes since GCC 10.

Reviewed By: aaron.ballman, MaskRay

Spies: #clang-vendors, beanz, JDevlieghere, Michael137, MaskRay, sstefan1, jplehr, cfe-commits, lldb-commits, dmgreen, jdoerfert, wenlei, wlei

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

show more ...

Stop trying to fixup 'overloadable' prototypeless functions.

While investigating something else, I discovered that a prototypeless
function with 'overloadable' was having the attribute left on the
d

Stop trying to fixup 'overloadable' prototypeless functions.

While investigating something else, I discovered that a prototypeless
function with 'overloadable' was having the attribute left on the
declaration, which caused 'ambiguous' call errors later on. This lead to
some confusion. This patch removes the 'overloadable' attribute from
the declaration and leaves it as prototypeless, instead of trying to
make it variadic.

show more ...

Default implicit function pointer conversions diagnostic to be an error

Implicitly converting between incompatible function pointers in C is
currently a default-on warning (it is an error in C++). H

Default implicit function pointer conversions diagnostic to be an error

Implicitly converting between incompatible function pointers in C is
currently a default-on warning (it is an error in C++). However, this
is very poor security posture. A mismatch in parameters or return
types, or a mismatch in calling conventions, etc can lead to
exploitable security vulnerabilities. Rather than allow this unsafe
practice with a warning, this patch strengthens the warning to be an
error (while still allowing users the ability to disable the error or
the warning entirely to ease migration). Users should either ensure the
signatures are correctly compatible or they should use an explicit cast
if they believe that's more reasonable.

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

show more ...

Add -Wno-strict-prototypes to C tests; NFC

This patch adds -Wno-strict-prototypes to all of the test cases that
use functions without prototypes, but not as the primary concern of the
test. e.g., at

Add -Wno-strict-prototypes to C tests; NFC

This patch adds -Wno-strict-prototypes to all of the test cases that
use functions without prototypes, but not as the primary concern of the
test. e.g., attributes testing whether they can/cannot be applied to a
function without a prototype, etc.

This is done in preparation for enabling -Wstrict-prototypes by
default.

show more ...

Check for the overloadable attribute in all the appropriate syntactic locations

When forming the function type from a declarator, we look for an
overloadable attribute before issuing a diagnostic in

Check for the overloadable attribute in all the appropriate syntactic locations

When forming the function type from a declarator, we look for an
overloadable attribute before issuing a diagnostic in C about a
function signature containing only .... When the attribute is present,
we allow such a declaration for compatibility with the overloading
rules in C++. However, we were not looking for the attribute in all of
the places it is legal to write it on a declarator and so we only
accepted the signature in some forms and incorrectly rejected the
signature in others.

We now check for the attribute preceding the declarator instead of only
being applied to the declarator directly.

show more ...

Fix an accepts-invalid issue with [[]] attributes in the type position in C

A user reported an issue to me via email that Clang was accepting some
code that GCC was rejecting. After investigation, i

Fix an accepts-invalid issue with [[]] attributes in the type position in C

A user reported an issue to me via email that Clang was accepting some
code that GCC was rejecting. After investigation, it turned out to be a
general problem of us failing to properly reject attributes written in
the type position in C when they don't apply to types. The root cause
was a terminology issue -- we sometimes use "CXX11Attr" to mean [[]] in
C++11 mode and sometimes [[]] in general -- and this came back to bite
us because in this particular case, it really meant [[]] in C++ mode.

I fixed the issue by introducing a new function
AttributeCommonInfo::isStandardAttributeSyntax() to represent [[]] in
either C or C++ mode.

This fix pointed out that we've had the issue in some of our existing
tests, which have all been corrected. This resolves
https://bugs.llvm.org/show_bug.cgi?id=50954.

show more ...

[Sema][C++] Propagate conversion kind to specialize the diagnostics

Compute and propagate conversion kind to diagnostics helper in C++
to provide more specific diagnostics about incorrect implicit
c

[Sema][C++] Propagate conversion kind to specialize the diagnostics

Compute and propagate conversion kind to diagnostics helper in C++
to provide more specific diagnostics about incorrect implicit
conversions in assignments, initializations, params, etc...

Duplicated some diagnostics as errors because C++ is more strict.

Tags: #clang

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

show more ...

[Sema] Deduplicate some availability checking logic

Before this commit, we emit unavailable errors for calls to functions during
overload resolution, and for references to all other declarations in

[Sema] Deduplicate some availability checking logic

Before this commit, we emit unavailable errors for calls to functions during
overload resolution, and for references to all other declarations in
DiagnoseUseOfDecl. The early checks during overload resolution aren't as good as
the DiagnoseAvailabilityOfDecl based checks, as they error on the code from
PR40991. This commit fixes this by removing the early checking.

llvm.org/PR40991
rdar://48564179

Differential revision: https://reviews.llvm.org/D59394

llvm-svn: 356599

show more ...

[Sema] Allow unmarked overloadable functions.

This patch extends the `overloadable` attribute to allow for one
function with a given name to not be marked with the `overloadable`
attribute. The over

[Sema] Allow unmarked overloadable functions.

This patch extends the `overloadable` attribute to allow for one
function with a given name to not be marked with the `overloadable`
attribute. The overload without the `overloadable` attribute will not
have its name mangled.

So, the following code is now legal:

void foo(void) __attribute__((overloadable));
void foo(int);
void foo(float) __attribute__((overloadable));

In addition, this patch fixes a bug where we'd accept code with
`__attribute__((overloadable))` inconsistently applied. In other words,
we used to accept:

void foo(void);
void foo(void) __attribute__((overloadable));

But we will do this no longer, since it defeats the original purpose of
requiring `__attribute__((overloadable))` on all redeclarations of a
function.

This breakage seems to not be an issue in practice, since the only code
I could find that had this pattern often looked like:

void foo(void);
void foo(void) __attribute__((overloadable)) __asm__("foo");
void foo(int) __attribute__((overloadable));

...Which can now be simplified by simply removing the asm label and
overloadable attribute from the redeclaration of `void foo(void);`

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

llvm-svn: 306467

show more ...

[test] Make absolute line numbers relative; NFC

Done to remove noise from https://reviews.llvm.org/D32332 (and to make
this test more resilient to changes in general).

llvm-svn: 305947

[Sema] Make typeof(OverloadedFunctionName) not a pointer.

We were sometimes doing a function->pointer conversion in
Sema::CheckPlaceholderExpr, which isn't the job of CheckPlaceholderExpr.

So, when

[Sema] Make typeof(OverloadedFunctionName) not a pointer.

We were sometimes doing a function->pointer conversion in
Sema::CheckPlaceholderExpr, which isn't the job of CheckPlaceholderExpr.

So, when we saw typeof(OverloadedFunctionName), where
OverloadedFunctionName referenced a name with only one function that
could have its address taken, we'd give back a function pointer type
instead of a function type. This is incorrect.

I kept the logic for doing the function pointer conversion in
resolveAndFixAddressOfOnlyViableOverloadCandidate because it was more
consistent with existing ResolveAndFix* methods.

llvm-svn: 302506

show more ...

[Sema] Relax overloading restrictions in C.

This patch allows us to perform incompatible pointer conversions when
resolving overloads in C. So, the following code will no longer fail to
compile (tho

[Sema] Relax overloading restrictions in C.

This patch allows us to perform incompatible pointer conversions when
resolving overloads in C. So, the following code will no longer fail to
compile (though it will still emit warnings, assuming the user hasn't
opted out of them):

```
void foo(char *) __attribute__((overloadable));
void foo(int) __attribute__((overloadable));

void callFoo() {
unsigned char bar[128];
foo(bar); // selects the char* overload.
}
```

These conversions are ranked below all others, so:

A. Any other viable conversion will win out
B. If we had another incompatible pointer conversion in the example
above (e.g. `void foo(int *)`), we would complain about
an ambiguity.

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

llvm-svn: 280553

show more ...

[Sema] Create a separate group for incompatible function pointer warning

Give incompatible function pointer warning its own diagnostic group
but still leave it as a subgroup of incompatible-pointer-

[Sema] Create a separate group for incompatible function pointer warning

Give incompatible function pointer warning its own diagnostic group
but still leave it as a subgroup of incompatible-pointer-types. This is in
preparation to promote -Wincompatible-function-pointer-types to error on
darwin.

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

rdar://problem/12907612

llvm-svn: 275907

show more ...

[Sema] Allow implicit conversions of &overloaded_fn in C.

Also includes a minor ``enable_if`` docs update.

Currently, our address-of overload machinery will only allow implicit
conversions of overl

[Sema] Allow implicit conversions of &overloaded_fn in C.

Also includes a minor ``enable_if`` docs update.

Currently, our address-of overload machinery will only allow implicit
conversions of overloaded functions to void* in C. For example:

```
void f(int) __attribute__((overloadable));
void f(double) __attribute__((overloadable, enable_if(0, "")));

void *fp = f; // OK. This is C and the target is void*.
void (*fp2)(void) = f; // Error. This is C, but the target isn't void*.
```

This patch makes the assignment of `fp2` select the `f(int)` overload,
rather than emitting an error (N.B. you'll still get a warning about the
`fp2` assignment if you use -Wincompatible-pointer-types).

Differential Revision: http://reviews.llvm.org/D13704

llvm-svn: 264132

show more ...

[Sema] Allow C conversions in C overload logic

C allows for some implicit conversions that C++ does not, e.g. void* ->
char*. This patch teaches clang that these conversions are okay when
dealing wi

[Sema] Allow C conversions in C overload logic

C allows for some implicit conversions that C++ does not, e.g. void* ->
char*. This patch teaches clang that these conversions are okay when
dealing with overloads in C.

Differential Revision: http://reviews.llvm.org/D13604

llvm-svn: 249995

show more ...

Replacing a custom diagnostic with a more standard one. No functional change intended.

llvm-svn: 195770

Added the attribute name to the err_attribute_wrong_number_arguments diagnostic for clarity; updated almost all of the affected test cases.

Thanks to Fariborz Jahanian for the suggestion!

llvm-svn:

Added the attribute name to the err_attribute_wrong_number_arguments diagnostic for clarity; updated almost all of the affected test cases.

Thanks to Fariborz Jahanian for the suggestion!

llvm-svn: 186980

show more ...

Correcting the NSObject and Overloadable attribute diagnostics so that the count reported matches reality.

llvm-svn: 186936

Reinstate r185229, reverted in r185256, with a tweak: further ignore the
standard's rule that an extern "C" declaration conflicts with any entity in the
global scope with the same name. Now we only c

Reinstate r185229, reverted in r185256, with a tweak: further ignore the
standard's rule that an extern "C" declaration conflicts with any entity in the
global scope with the same name. Now we only care if the global scope entity is
a variable declaration (and so might have the same mangled name as the extern
"C" declaration). This has been reported as a standard defect.

Original commit message:

PR7927, PR16247: Reimplement handling of matching extern "C" declarations
across scopes.

When we declare an extern "C" name that is not a redeclaration of an entity in
the same scope, check whether it redeclares some extern "C" entity from another
scope, and if not, check whether it conflicts with a (non-extern-"C") entity in
the translation unit.

When we declare a name in the translation unit that is not a redeclaration,
check whether it conflicts with any extern "C" entities (possibly from other
scopes).

llvm-svn: 185281

show more ...

Revert r185229 as it breaks compilation of <windows.h>

llvm-svn: 185256

PR7927, PR16247: Reimplement handling of matching extern "C" declarations
across scopes.

When we declare an extern "C" name that is not a redeclaration of an entity in
the same scope, check whether

PR7927, PR16247: Reimplement handling of matching extern "C" declarations
across scopes.

When we declare an extern "C" name that is not a redeclaration of an entity in
the same scope, check whether it redeclares some extern "C" entity from another
scope, and if not, check whether it conflicts with a (non-extern-"C") entity in
the translation unit.

When we declare a name in the translation unit that is not a redeclaration,
check whether it conflicts with any extern "C" entities (possibly from other
scopes).

llvm-svn: 185229

show more ...

Modify how the -verify flag works. Currently, the verification string and
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unex

Modify how the -verify flag works. Currently, the verification string and
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:

// expect-error{{candidate function has different number of parameters}}

will match the following error messages from Clang:

candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters

It will also match these other error messages:

candidate function
function has different number of parameters
number of parameters

This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:

87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)

llvm-svn: 146619

show more ...

Make sure that we diagnose attribute((overloadable)) functions without
prototypes. Fixes PR7738.

llvm-svn: 110443

Check compatibility of vector types using their canonicalizations.
Fixes an assertion arising C overload analysis, but really I can't imagine
that this wouldn't cause a thousand other uncaught failur

Check compatibility of vector types using their canonicalizations.
Fixes an assertion arising C overload analysis, but really I can't imagine
that this wouldn't cause a thousand other uncaught failures.

Fixes PR6600.

llvm-svn: 98400

show more ...

Change the printing of OR_Deleted overload results to print all the candidates,
not just the viable ones. This is reasonable because the most common use of
deleted functions is to exclude some impli

Change the printing of OR_Deleted overload results to print all the candidates,
not just the viable ones. This is reasonable because the most common use of
deleted functions is to exclude some implicit conversion during calls; users
therefore will want to figure out why some other options were excluded.

Started sorting overload results. Right now it just sorts by location in the
translation unit (after putting viable functions first), but we can do better than
that.

Changed bool OnlyViable parameter to PrintOverloadCandidates to an enum for better
self-documentation.

llvm-svn: 92990

show more ...