[Clang] Emit a diagnostic note at the class declaration when the method definition does not match any declaration. (#110638)

Fixes #110558.

In this patch, we will emit a diagnostic note pointing

[Clang] Emit a diagnostic note at the class declaration when the method definition does not match any declaration. (#110638)

Fixes #110558.

In this patch, we will emit a diagnostic note pointing to the class
declaration when a method definition does not match any declaration.
This approach, similar to what GCC does, makes the diagnostic more
user-friendly.

---------

Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>

show more ...

[AST] Enhance the const expression evaluator to support error-dependent exprs.

Fix a crash when evaluating a constexpr function which contains
recovery-exprs. https://bugs.llvm.org/show_bug.cgi?id=4

[AST] Enhance the const expression evaluator to support error-dependent exprs.

Fix a crash when evaluating a constexpr function which contains
recovery-exprs. https://bugs.llvm.org/show_bug.cgi?id=46837

Would be nice to have constant expression evaluator support general template
value-dependent expressions, but it requires more work.

This patch is a good start I think, to handle the error-only
value-dependent expressions.

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

show more ...

[AST][RecoveryExpr] Build recovery expressions by default for C++.

Reland https://reviews.llvm.org/D76696
All known crashes have been fixed, another attemption.

We have rolled out this to all inter

[AST][RecoveryExpr] Build recovery expressions by default for C++.

Reland https://reviews.llvm.org/D76696
All known crashes have been fixed, another attemption.

We have rolled out this to all internal users for a while, didn't see
big issues, we consider it is stable enough.

Reviewed By: sammccall

Subscribers: rsmith, hubert.reinterpretcast, ebevhan, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

show more ...

Fix handling of default arguments in __attribute__((enable_if)).

We didn't properly build default argument expressions previously -- we
failed to build the wrapper CXXDefaultArgExpr node, which mean

Fix handling of default arguments in __attribute__((enable_if)).

We didn't properly build default argument expressions previously -- we
failed to build the wrapper CXXDefaultArgExpr node, which meant that
std::source_location misbehaved, and we didn't perform default argument
instantiation when necessary, which meant that dependent default
arguments in function templates didn't work at all.

show more ...

Fix __attribute__((enable_if)) to treat arguments with side-effects as
non-constant.

We previously failed the entire condition evaluation if an unmodeled
side-effect was encountered in an argument,

Fix __attribute__((enable_if)) to treat arguments with side-effects as
non-constant.

We previously failed the entire condition evaluation if an unmodeled
side-effect was encountered in an argument, even if that argument was
unused in the attribute's condition.

show more ...

Reinstate r359059, reverted in r359361, with a fix to properly prevent
us emitting the operand of __builtin_constant_p if it has side-effects.

Original commit message:

Fix interactions between __bu

Reinstate r359059, reverted in r359361, with a fix to properly prevent
us emitting the operand of __builtin_constant_p if it has side-effects.

Original commit message:

Fix interactions between __builtin_constant_p and constexpr to match
current trunk GCC.

GCC permits information from outside the operand of
__builtin_constant_p (but in the same constant evaluation context) to be
used within that operand; clang now does so too. A few other minor
deviations from GCC's behavior showed up in my testing and are also
fixed (matching GCC):
* Clang now supports nullptr_t as the argument type for
__builtin_constant_p
* Clang now returns true from __builtin_constant_p if called with a
null pointer
* Clang now returns true from __builtin_constant_p if called with an
integer cast to pointer type

llvm-svn: 359367

show more ...

Revert Fix interactions between __builtin_constant_p and constexpr to match current trunk GCC.

This reverts r359059 (git commit 0b098754b73f3b96d00ecb1c7605760b11c90298)

llvm-svn: 359361

Fix interactions between __builtin_constant_p and constexpr to match
current trunk GCC.

GCC permits information from outside the operand of
__builtin_constant_p (but in the same constant evaluation

Fix interactions between __builtin_constant_p and constexpr to match
current trunk GCC.

GCC permits information from outside the operand of
__builtin_constant_p (but in the same constant evaluation context) to be
used within that operand; clang now does so too. A few other minor
deviations from GCC's behavior showed up in my testing and are also
fixed (matching GCC):
* Clang now supports nullptr_t as the argument type for
__builtin_constant_p
* Clang now returns true from __builtin_constant_p if called with a
null pointer
* Clang now returns true from __builtin_constant_p if called with an
integer cast to pointer type

llvm-svn: 359059

show more ...

[8.0 Regression] Fix handling of `__builtin_constant_p` inside template arguments, enumerators, case statements, and the enable_if attribute.

Summary:
The following code is accepted by Clang 7 and p

[8.0 Regression] Fix handling of `__builtin_constant_p` inside template arguments, enumerators, case statements, and the enable_if attribute.

Summary:
The following code is accepted by Clang 7 and prior but rejected by the upcoming 8 release and in trunk [1]

```
// error {{never produces a constant expression}}
void foo(const char* s) __attribute__((enable_if(__builtin_constant_p(*s) == false, "trap"))) {}
void test() { foo("abc"); }
```

Prior to Clang 8, the call to `__builtin_constant_p` was a constant expression returning false. Currently, it's not a valid constant expression.

The bug is caused because we failed to set `InConstantContext` when attempting to evaluate unevaluated constant expressions.

[1] https://godbolt.org/z/ksAjmq

Reviewers: rsmith, hans, sbenza

Reviewed By: rsmith

Subscribers: kristina, cfe-commits

Tags: #clang

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

llvm-svn: 355743

show more ...

Emit diagnostic note when calling an invalid function declaration.

The comment said it was intentionally not emitting any diagnostic
because the declaration itself was already diagnosed. However,
ev

Emit diagnostic note when calling an invalid function declaration.

The comment said it was intentionally not emitting any diagnostic
because the declaration itself was already diagnosed. However,
everywhere else that wants to not emit a diagnostic without an extra
note emits note_invalid_subexpr_in_const_expr instead, which gets
suppressed later.

This was the only place which did not emit a diagnostic note.

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

llvm-svn: 343867

show more ...

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

Fix PR31934: forming refs to functions with enable_if attrs.

llvm-svn: 300283

Update the tests to match the typo fix done in r292015

llvm-svn: 292016

Consistently use a ConstantEvaluated context for expressions in attributes,
except for those with the "attributes are unevaluated contexts" flag.

llvm-svn: 291358

[Sema] Fix a bug in enable_if condition instantiation.

During template instantiation, we currently fall back to just calling
Sema::SubstExpr for enable_if attributes that aren't value-dependent or
t

[Sema] Fix a bug in enable_if condition instantiation.

During template instantiation, we currently fall back to just calling
Sema::SubstExpr for enable_if attributes that aren't value-dependent or
type-dependent. Since Sema::SubstExpr strips off any implicit casts
we've added to an expression, it's possible that this behavior will
leave us with an enable_if condition that's just a DeclRefExpr.
Conditions like that deeply confuse Sema::CheckEnableIf.

llvm-svn: 287187

show more ...

Use the member function location in enable_if diagnostics.

Before:
<stdin>:3:3: error: no matching member function for call to 'bar'
Foo().bar();
^

After:
<stdin>:3:9: error: no matching member

Use the member function location in enable_if diagnostics.

Before:
<stdin>:3:3: error: no matching member function for call to 'bar'
Foo().bar();
^

After:
<stdin>:3:9: error: no matching member function for call to 'bar'
Foo().bar();
^

llvm-svn: 287154

show more ...

[Sema] Fix a crash on variadic enable_if functions.

Currently, when trying to evaluate an enable_if condition, we try to
evaluate all arguments a user passes to a function. Given that we can't
use v

[Sema] Fix a crash on variadic enable_if functions.

Currently, when trying to evaluate an enable_if condition, we try to
evaluate all arguments a user passes to a function. Given that we can't
use variadic arguments from said condition anyway, not converting them
is a reasonable thing to do. So, this patch makes us ignore any varargs
when attempting to check an enable_if condition.

We'd crash because, in order to convert an argument, we need its
ParmVarDecl. Variadic arguments don't have ParmVarDecls.

llvm-svn: 278471

show more ...

[Sema] Fix value-dependent enable_if bug.

This patch fixes a bug where we would assume all value-dependent
enable_if conditions give successful results.

Instead, we consider value-dependent enable_

[Sema] Fix value-dependent enable_if bug.

This patch fixes a bug where we would assume all value-dependent
enable_if conditions give successful results.

Instead, we consider value-dependent enable_if conditions to always
fail. While this isn't ideal, this is the best we can realistically do
without changing both enable_if's semantics and large parts of Sema
(specifically, all of the parts that don't expect type dependence to
come out of nowhere, and that may interact with overload resolution).

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

llvm-svn: 269154

show more ...

[Sema] Fix PR27122: ICE with enable_if+ill-formed call.

In some cases, when we encounter a direct function call with an
incorrect number of arguments, we'll emit a diagnostic, and pretend that
the c

[Sema] Fix PR27122: ICE with enable_if+ill-formed call.

In some cases, when we encounter a direct function call with an
incorrect number of arguments, we'll emit a diagnostic, and pretend that
the call to the function was valid. For example, in C:

int foo();
int a = foo(1);

Prior to this patch, we'd get an ICE if foo had an enable_if attribute,
because CheckEnableIf assumes that the number of arguments it gets
passed is valid for the function it's passed. Now, we check that the
number of args looks valid prior to checking enable_if conditions.

This fix was not done inside of CheckEnableIf because the problem
presently can only occur in one caller of CheckEnableIf (ActOnCallExpr).
Additionally, checking inside of CheckEnableIf would make us emit
multiple diagnostics for the same error (one "enable_if failed", one
"you gave this function the wrong number of arguments"), which seems
worse than just complaining about the latter.

llvm-svn: 264975

show more ...

[Sema] Allow casting of some overloaded functions

Some functions can't have their address taken. If we encounter an
overload set where only one of the candidates can have its address
taken, we shoul

[Sema] Allow casting of some overloaded functions

Some functions can't have their address taken. If we encounter an
overload set where only one of the candidates can have its address
taken, we should automatically select that candidate in cast
expressions.

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

llvm-svn: 263887

show more ...

Add tests for `&enable_if_function` diagnostics.

The introduction of pass_object_size fixed a few bugs related to taking
the address of a function with enable_if attributes. This patch adds
tests fo

Add tests for `&enable_if_function` diagnostics.

The introduction of pass_object_size fixed a few bugs related to taking
the address of a function with enable_if attributes. This patch adds
tests for the cases that were fixed.

llvm-svn: 254646

show more ...

[modules] Rationalize the behavior of Decl::declarationReplaces, and in
particular don't assume that two declarations of the same kind in the same
context are declaring the same entity. That's not tr

[modules] Rationalize the behavior of Decl::declarationReplaces, and in
particular don't assume that two declarations of the same kind in the same
context are declaring the same entity. That's not true when the same name is
declared multiple times as internal-linkage symbols within a module.
(getCanonicalDecl is cheap now, so we can just use it here.)

llvm-svn: 251898

show more ...

[Sema] Fix address-of + enable_if overloading logic

Previously, our logic when taking the address of an overloaded function
would not consider enable_if attributes, so long as all of the enable_if
c

[Sema] Fix address-of + enable_if overloading logic

Previously, our logic when taking the address of an overloaded function
would not consider enable_if attributes, so long as all of the enable_if
conditions on a given candidate were true. So, two functions with
identical signatures (one with enable_if attributes, the other without),
would be considered equally good overloads. If we were calling the
function instead of taking its address, then the function with enable_if
attributes would be preferred.

This patch makes us prefer the candidate with enable_if regardless of if
we're calling or taking the address of an overloaded function.

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

llvm-svn: 250486

show more ...

[Sema] Make `&function_with_enable_if_attrs` an error

This fixes a bug where one can take the address of a conditionally
enabled function to drop its enable_if guards. For example:

int foo(int a)

[Sema] Make `&function_with_enable_if_attrs` an error

This fixes a bug where one can take the address of a conditionally
enabled function to drop its enable_if guards. For example:

int foo(int a) __attribute__((enable_if(a > 0, "")));
int (*p)(int) = &foo;
int result = p(-1); // compilation succeeds; calls foo(-1)

Overloading logic has been updated to reflect this change, as well.

Functions with enable_if attributes that are always true are still
allowed to have their address taken.

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

llvm-svn: 250090

show more ...

Make incomplete type errors better with enable_if

This patch fixes the order in which we evaluate the different ways that
a function call could be disallowed. Now, if you call a non-overloaded
funct

Make incomplete type errors better with enable_if

This patch fixes the order in which we evaluate the different ways that
a function call could be disallowed. Now, if you call a non-overloaded
function with an incomplete type and failing enable_if, we'll prioritize
reporting the more obvious error (use of incomplete type) over reporting
the failing enable_if.

Thanks to Ettore Speziale for the patch!

llvm-svn: 248595

show more ...