Clang has a diagnostic for the what happens when an elaborated type
implicitly creates a tag declaration and the initial tag lookup fails,
but the redeclaration lookup succeeds and finds a non-tag type. However,
it wasn't tested, and looked like dead code. After much staring, we
discovered how to exercise it, and are now committing the test for
posterity.
In this example, the tag lookup will not find A, but then when we go to
insert a declaration of A at global scope, we discover the template
friend, which is not a tag type.
struct C {
template <typename> friend struct A;
};
struct B {
struct A *p;
};
llvm-svn: 283235
Treating large 0x*LL literals as signed instead of unsigned is not a
conforming language extension, so move it out of -fms-extensions.
Came up in PR30605
llvm-svn: 283227
Previously if a file-level function was defined inside befriending
template class, it always was treated as defined. For instance, the code like:
```
int func(int x);
template<typename T> class C1 {
friend int func(int x) { return x; }
};
template<typename T> class C2 {
friend int func(int x) { return x; }
};
```
could not be compiled due to function redefinition, although not of the templates
is instantiated. Moreover, the body of friend function can contain use of template
parameters, attempt to get definition of such function outside any instantiation
causes compiler abnormal termination.
Other compilers (gcc, icc) follow viewpoint that the body of the function defined
in friend declaration becomes available when corresponding class is instantiated.
This patch implements this viewpoint in clang.
Definitions introduced by friend declarations in template classes are not added
to the redeclaration chain of corresponding function. Only when the template is
instantiated, instantiation of the function definition is placed to the chain.
The fix was made in collaboration with Richard Smith.
This change fixes PR8035, PR17923, PR22307 and PR25848.
Differential Revision: http://reviews.llvm.org/D16989
llvm-svn: 283207
declarations.
This commit ensures that the correct record type is printed out for the
using declarations that represent C++ inherited constructors.
It fixes a regression introduced in r274049 which changed the name that's
stored in the using declarations that correspond to inherited constructors.
Differential Revision: https://reviews.llvm.org/D25131
llvm-svn: 283105
declarations.
This commit ensures that the correct record type is printed out for the
using declarations that represent C++ inherited constructors.
It fixes a regression introduced in r274049 which changed the name that's
stored in the using declarations that correspond to inherited constructors.
Differential Revision: https://reviews.llvm.org/D25131
llvm-svn: 283102
Summary:
Also makes -fcoroutines_ts to be both a Driver and CC1 flag.
Patch mostly by EricWF.
Reviewers: rnk, cfe-commits, rsmith, EricWF
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D25130
llvm-svn: 283064
With templated classes, is possible to not be able to determine is a member
function is a special member function before the class is instantiated. Only
these special member functions can be defaulted. In some cases, knowing
whether a function is a special member function can't be determined until
instantiation, so an uninstantiated function could possibly be defaulted too.
Add a case to the error diagnostic when the function marked with a default is
not known to be a special member function.
llvm-svn: 282989
Summary: The title says it all.
Reviewers: rsmith, GorNishanov
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D25078
llvm-svn: 282973
In some cases, non-special member functions were being marked as being defaulted
in templated classes. This can cause interactions with later code that expects
the default function to be one of the specific member functions. Fix the check
so that templated class members are checked the same way as non-templated class
members are.
llvm-svn: 282547
This mostly behaves cl.exe's behavior, even though clang-cl is stricter in some
corner cases and more lenient in others (see the included test).
To make the uuid declared previously here diagnostic work correctly, tweak
stripTypeAttributesOffDeclSpec() to keep attributes in the right order.
https://reviews.llvm.org/D24469
llvm-svn: 281367
r280553 introduced an issue where we'd emit ambiguity errors for code
like:
```
void foo(int *, int);
void foo(unsigned int *, unsigned int);
void callFoo() {
unsigned int i;
foo(&i, 0); // ambiguous: int->unsigned int is worse than int->int,
// but unsigned int*->unsigned int* is better than
// int*->int*.
}
```
This patch fixes this issue by changing how we handle ill-formed (but
valid) implicit conversions. Candidates with said conversions now always
rank worse than candidates without them, and two candidates are
considered to be equally bad if they both have these conversions for
the same argument.
Additionally, this fixes a case in C++11 where we'd complain about an
ambiguity in a case like:
```
void f(char *, int);
void f(const char *, unsigned);
void g() { f("abc", 0); }
```
...Since conversion to char* from a string literal is considered
ill-formed in C++11 (and deprecated in C++03), but we accept it as an
extension.
llvm-svn: 280847
copy-initialization. We previously got this wrong in a couple of ways:
- we only looked for copy / move constructors and constructor templates for
this copy, and thus would fail to copy in cases where doing so should use
some other constructor (but see core issue 670),
- we mishandled the special case for disabling user-defined conversions that
blocks infinite recursion through repeated application of a copy constructor
(applying it in slightly too many cases) -- though as far as I can tell,
this does not ever actually affect the result of overload resolution, and
- we misapplied the special-case rules for constructors taking a parameter
whose type is a (reference to) the same class type by incorrectly assuming
that only happens for copy/move constructors (it also happens for
constructors instantiated from templates and those inherited from base
classes).
These changes should only affect strange corner cases (for instance, where the
copy constructor exists but has a non-const-qualified parameter type), so for
the most part it only causes us to produce more 'candidate' notes, but see the
test changes for other cases whose behavior is affected.
llvm-svn: 280776
Summary:
This attribute specifies expectations about the initialization of static and
thread local variables. Specifically that the variable has a
[constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization)
according to the rules of [basic.start.static]. Failure to meet this expectation
will result in an error.
Static objects with constant initializers avoid hard-to-find bugs caused by
the indeterminate order of dynamic initialization. They can also be safely
used by other static constructors across translation units.
This attribute acts as a compile time assertion that the requirements
for constant initialization have been met. Since these requirements change
between dialects and have subtle pitfalls it's important to fail fast instead
of silently falling back on dynamic initialization.
```c++
// -std=c++14
#define SAFE_STATIC __attribute__((require_constant_initialization)) static
struct T {
constexpr T(int) {}
~T();
};
SAFE_STATIC T x = {42}; // OK.
SAFE_STATIC T y = 42; // error: variable does not have a constant initializer
// copy initialization is not a constant expression on a non-literal type.
```
This attribute can only be applied to objects with static or thread-local storage
duration.
Reviewers: majnemer, rsmith, aaron.ballman
Subscribers: jroelofs, cfe-commits
Differential Revision: https://reviews.llvm.org/D23385
llvm-svn: 280525
Summary:
This attribute specifies expectations about the initialization of static and
thread local variables. Specifically that the variable has a
[constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization)
according to the rules of [basic.start.static]. Failure to meet this expectation
will result in an error.
Static objects with constant initializers avoid hard-to-find bugs caused by
the indeterminate order of dynamic initialization. They can also be safely
used by other static constructors across translation units.
This attribute acts as a compile time assertion that the requirements
for constant initialization have been met. Since these requirements change
between dialects and have subtle pitfalls it's important to fail fast instead
of silently falling back on dynamic initialization.
```c++
// -std=c++14
#define SAFE_STATIC __attribute__((require_constant_initialization)) static
struct T {
constexpr T(int) {}
~T();
};
SAFE_STATIC T x = {42}; // OK.
SAFE_STATIC T y = 42; // error: variable does not have a constant initializer
// copy initialization is not a constant expression on a non-literal type.
```
This attribute can only be applied to objects with static or thread-local storage
duration.
Reviewers: majnemer, rsmith, aaron.ballman
Subscribers: jroelofs, cfe-commits
Differential Revision: https://reviews.llvm.org/D23385
llvm-svn: 280516
explicit specialization to a warning for C++98 mode (this is a defect report
resolution, so per our informal policy it should apply in C++98), and turn
the warning on by default for C++11 and later. In all cases where it fires, the
right thing to do is to remove the pointless explicit instantiation.
llvm-svn: 280308
In certain cases (mostly coming from modules), Sema's idea of the StdNamespace
does not point to the first declaration of namespace std.
Patch by Cristina Cristescu!
Reviewed by Richard Smith.
llvm-svn: 279371
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
Reapply r277787. For memset (and others) we can get diagnostics like:
struct stat { int x; };
void foo(struct stat *stamps) {
bzero(stamps, sizeof(stamps));
memset(stamps, 0, sizeof(stamps));
}
t.c:7:28: warning: 'memset' call operates on objects of type 'struct stat' while the size is based on a different type 'struct stat *' [-Wsizeof-pointer-memaccess]
memset(stamps, 0, sizeof(stamps));
~~~~~~ ^~~~~~
t.c:7:28: note: did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)?
memset(stamps, 0, sizeof(stamps));
^~~~~~
This patch implements the same class of warnings for bzero.
Differential Revision: https://reviews.llvm.org/D22525
rdar://problem/18963514
llvm-svn: 278264
If the return type is a pointer and the function returns the reference to a
pointer, don't warn since only the value is returned, not the reference.
If a reference function parameter appears in the reference chain, don't warn
since binding happens at the caller scope, so addresses returned are not
to local stack. This includes default arguments as well.
llvm-svn: 277889
For builtin logical operators, there is a well-defined ordering of argument
evaluation. For overloaded operator of the same type, there is no argument
evaluation order, similar to other function calls. When both are present,
uninstantiated templates with an operator&& is treated as an unresolved
function call. Unresolved function calls are treated as normal function calls,
and may result in false positives when the builtin logical operator is used.
Have the unsequenced checker ignore dependent expressions to avoid this
false positive. The check also happens in template instantiations to catch
when the overloaded operator is used.
llvm-svn: 277866
For memset (and others) we can get diagnostics like:
struct stat { int x; };
void foo(struct stat *stamps) {
bzero(stamps, sizeof(stamps));
memset(stamps, 0, sizeof(stamps));
}
t.c:7:28: warning: 'memset' call operates on objects of type 'struct stat' while the size is based on a different type 'struct stat *' [-Wsizeof-pointer-memaccess]
memset(stamps, 0, sizeof(stamps));
~~~~~~ ^~~~~~
t.c:7:28: note: did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)?
memset(stamps, 0, sizeof(stamps));
^~~~~~
This patch implements the same class of warnings for bzero.
Differential Revision: https://reviews.llvm.org/D22525
rdar://problem/18963514
llvm-svn: 277787
Fix a crash under -Wthread-safety when finding the destructor for a
lifetime-extending reference.
A patch by Nandor Licker!
Differential Revision: https://reviews.llvm.org/D22419
llvm-svn: 277522
Additionally, for pre-C++1z, instead of forbidding a lambda's closure type from being a literal type through circumlocutorily setting HasNonLiteralTypeFieldsOrBases falsely to true -- handle lambda's more directly in CXXRecordDecl::isLiteral().
One additional small step towards implementing constexpr-lambdas.
Thanks to Richard Smith for his review!
https://reviews.llvm.org/D22662
llvm-svn: 276514
decomposition declarations.
There are a couple of things in the wording that seem strange here:
decomposition declarations are permitted at namespace scope (which we partially
support here) and they are permitted as the declaration in a template (which we
reject).
llvm-svn: 276492
In atomic builtins, we assumed that the LValue conversion on the first
argument would succeed. So, we would crash given code like:
```
void ovl(char);
void ovl(int);
__atomic_store_n(ovl, 0, 0);
```
This patch makes us not assume that said conversion is successful. :)
llvm-svn: 276232
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
It's a patch for PR28050. Seems like overloading resolution wipes out
the first standard conversion sequence (before user-defined conversion)
in case of deprecated string literal conversion.
Differential revision: https://reviews.llvm.org/D21228
Patch by Alexander Makarov
llvm-svn: 275970
they're redeclarations. This is necessary in order for name lookup to correctly
find the most recent declaration of the name (which affects default template
argument lookup and cross-module merging, among other things).
llvm-svn: 275612
Reid Kleckner