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
Extend the __declspec(dll*) attribute to cover ObjC interfaces. This was
requested by Microsoft for their ObjC support. Cover both import and export.
This only adds the semantic analysis portion of the support, code-generation
still remains outstanding. Add some basic initial documentation on the
attributes that were previously empty. Tweak the previous tests to use the
relative expected-warnings to make the tests easier to read.
llvm-svn: 275610
This patch implements PR#22821.
Taking the address of a packed member is dangerous since the reduced
alignment of the pointee is lost. This can lead to memory alignment
faults in some architectures if the pointer value is dereferenced.
This change adds a new warning to clang emitted when taking the address
of a packed member. A packed member is either a field/data member
declared as attribute((packed)) or belonging to a struct/class
declared as such. The associated flag is -Waddress-of-packed-member.
Conversions (either implicit or via a valid casting) to pointer types
with lower or equal alignment requirements (e.g. void* or char*)
silence the warning.
This change also adds a new error diagnostic when the user attempts to
bind a reference to a packed member, regardless of the alignment.
Differential Revision: https://reviews.llvm.org/D20561
llvm-svn: 275417
After thinking about it, we don't really need to forbid
BuiltinTemplateDecls explicitly. The restriction doesn't really buy us
anything.
llvm-svn: 275078
When we have template arguments, we have a function and a pattern, the variable
in init-capture belongs to the pattern decl when checking if the lhs of
"max = current" is modifiable:
auto find = [max = init](auto current) {
max = current;
};
In function isReferenceToNonConstCapture, we handle the case where the decl
context for the variable is not part of the current context.
Instead of crashing, we emit an error message:
cannot assign to a variable captured by copy in a non-mutable lambda
rdar://26997922
llvm-svn: 274392
This patch adds a __nth_element builtin that allows fetching the n-th type of a
parameter pack with very little compile-time overhead. The patch was inspired by
r252036 and r252115 by David Majnemer, which add a similar __make_integer_seq
builtin for efficiently creating a std::integer_sequence.
Reviewed as D15421. http://reviews.llvm.org/D15421
llvm-svn: 274316
function-style cast to a non-dependent type which is then used in an invalid
way. We'd lose the "type dependent" bit here, and downstream Sema processing
would then discard the expression if it was used in a context where its type
rendered it invalid.
llvm-svn: 274267
Original patch by Stefan Bühler http://reviews.llvm.org/D12834
Difference between original and this one:
- fixed all failing tests
- fixed mangling for global variable outside namespace
- emit ABI tags for guards and local names
- clang-format + other stylistic changes
- significantly reworked patch according to Richard's suggestions
Sema part, committed before http://reviews.llvm.org/D17567
Differential revision: http://reviews.llvm.org/D18035
llvm-svn: 274222
constructor would be; this is effectively required by P0136R1. This has the
effect of exposing the validity of the base class initialization steps to
SFINAE checks.
llvm-svn: 274088
Nico Weber