designator" diagnostic with more correct and more human-friendly "cannot take
address of rvalue of type 'T'".
For the case of & &T::f, provide a custom diagnostic, rather than unhelpfully
saying "cannot take address of rvalue of type '<overloaded function type>'".
For the case of &array_temporary, treat it just like a class temporary
(including allowing it as an extension); the existing diagnostic wording
for the class temporary case works fine.
llvm-svn: 174262
says, but that's a defect (to be filed). "Cls::purevfn()" is still an odr use.
Also fixes a bug that caused us to not mark the function referenced just
because we didn't want to mark it odr used.
llvm-svn: 174242
Prior to the patch, Clang does not properly promote types when a complex
integer operand is combined with an integer via a binary operator, or when
one is assigned to the other in either order. This patch detects when
promotion is needed (and permissible) and generates the necessary code.
The test assmes no target has the same size operands for "char" and
"long long," and that no target performs arithmetic on char operands without
extending them to a larger format first. If there are any targets for
which this is not the case, they should be XFAILed.
llvm-svn: 174181
__fp16 isn't covered by the standard, but this resolves the oddity that float
gets promoted when passed variadically, but not the smaller type. This is
required by the AArch64 ABI, and a sane action elsewhere.
llvm-svn: 173918
expressions which have undefined behavior due to multiple unsequenced
modifications or an unsequenced modification and use of a variable.
llvm-svn: 172690
In the source
static void f();
static void f();
template<typename T>
static void g() {
f();
}
static void f() {
}
void h() {
g<int>();
}
the call to f refers to the second decl, but it is only marked used at the end
of the translation unit during instantiation, after the third f decl has been
linked in.
With this patch we mark all subsequent decls used, so that it is easy to check
if a symbol is used or not.
llvm-svn: 171888
with respect to the lower "left-hand-side bitwidth" bits, even when negative);
see OpenCL spec 6.3j. This patch both implements this behaviour in the code
generator and "constant folding" bits of Sema, and also prevents tests
to detect undefinedness in terms of the weaker C99 or C++ specifications
from being applied.
llvm-svn: 171755
Along the way, fix a bug in CheckLiteralKind(), previously in diagnoseObjCLiteralComparison, where we didn't ignore parentheses
in boxed expressions for purpose of classification.
In other words, both @42 and @(42) should be classified as numeric
literals.
llvm-svn: 170931
CXXScalarValueInitExpr (or an ImplicitValueInitExpr), strip it back down to an
empty pair of parentheses so that the initialization code can tell that we're
performing value-initialization.
llvm-svn: 170867
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
Among other differences, GCC accepts
typedef int IA[];
typedef int A10[10];
static A10 *f(void);
static IA *f(void);
void g(void) {
(void)sizeof(*f());
}
but clang used to reject it with:
invalid application of 'sizeof' to an incomplete type 'IA' (aka 'int []')
The intention of c99's 6.2.7 seems to be that we should use the composite type
and accept as gcc does.
Doing the type merging required some extra fixes:
* Use the type from the function type in initializations, even if an parameter
is available.
* Fix the merging of the noreturn attribute in function types.
* Make CodeGen handle the fact that an parameter type can be different from
the corresponding type in the function type.
llvm-svn: 168895
objc_loadWeak. This retains and autorelease the weakly-refereced
object. This hidden autorelease sometimes makes __weak variable alive even
after the weak reference is erased, because the object is still referenced
by an autorelease pool. This patch overcomes this behavior by loading a
weak object via call to objc_loadWeakRetained(), followng it by objc_release
at appropriate place, thereby removing the hidden autorelease. // rdar://10849570
llvm-svn: 168740
Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.
No functionality changes are intended here (they will come when the predicates
start producing the right answers...).
llvm-svn: 168119
BinaryOperator::Opcode. This is bad form, and the behavior of the static_cast
in this case is unspecified according to the standard.
Fixes a warning that showed up from r167992 on self-host.
llvm-svn: 168010
positions of Objective-C methods.
It is possible to recover a lot of type information about
Objective-C methods from the reflective metadata for their
implementations. This information is not rich when it
comes to struct types, however, and it is not possible to
produce a type in the debugger's round-tripped AST which
will really do anything useful during type-checking.
Therefore we allow __unknown_anytype in these positions,
which essentially disables type-checking for that argument.
We infer the parameter type to be the unqualified type of
the argument expression unless that expression is an
explicit cast, in which case it becomes the type-as-written
of that cast.
rdar://problem/12565338
llvm-svn: 167896
This warning was failing to fire under ARC because of the implicit
lifetime casts added around the object literal expression.
<rdar://problem/11300873>, again.
llvm-svn: 167648
instantiate it if it can be instantiated and implicitly define it if it can be
implicitly defined. This matches g++'s approach. Remove some cases from
SemaOverload which were marking functions as referenced when just planning how
overload resolution would proceed; such cases are not actually references.
llvm-svn: 167514
found: if an overloaded operator& is present before a template definition,
the expression &T::foo is represented as a CXXOperatorCallExpr, not as a
UnaryOperator, so we didn't notice that it's permitted to reference a non-static
data member of an unrelated class.
While investigating this, I discovered another problem in this area: we are
treating template default arguments as unevaluated contexts during substitution,
resulting in performing incorrect checks for uses of non-static data members in
C++11. That is not fixed by this patch (I'll look into this soon; it's related
to the failure to correctly instantiate constexpr function templates), but was
resulting in this bug not firing in C++11 mode (except with -Wc++98-compat).
Original message:
PR14124: When performing template instantiation of a qualified-id outside of a
class, diagnose if the qualified-id instantiates to a non-static class member.
llvm-svn: 166385
initialized by a reference constant expression.
Our odr-use modeling still needs work here: we don't yet implement the 'set of
potential results of an expression' DR.
llvm-svn: 166361
Nick Lewycky