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
Previously, for a field with an invalid in-class initializer, we
would create a CXXDefaultInitExpr referring to a null Expr*.
This is not a good idea.
llvm-svn: 185216
r177473 made us correctly consider only those declarations in the
enclosing namespace scope when looking for a friend declaration. Under
ms-extensions mode, where we do some level of friend injection, this
meant that we were introducing a new tag type into a different scope
than what Microsoft actually does. Address this by only doing the
friend injection when we didn't see any tag with that name in any
outer scope. Fixes <rdar://problem/14250378>.
llvm-svn: 185100
side-effect is not sequenced before its value computation. Also fix a
mishandling of ?: expressions where the condition is constant that was
exposed by the tests for this.
llvm-svn: 185035
The old implementation of ms_struct in RecordLayoutBuilder was a
complete mess: it depended on complicated conditionals which didn't
really reflect the underlying logic, and placed a burden on users of
the resulting RecordLayout. This commit rips out almost all of the
old code, and replaces it with simple checks in
RecordLayoutBuilder::LayoutBitField.
This commit also fixes <rdar://problem/14252115>, a bug where class
inheritance would cause us to lay out bitfields incorrectly.
llvm-svn: 185018
When the decl that we're getting alignment for is a FieldDecl, and the field's
parent record is invalid, skip the actual field alignment calculation (and
return 1-byte alignment in the general case).
Also, assert in in getASTRecordLayout that the decl is valid. This was
inspired by PR16292; see also r184581 and r184751.
llvm-svn: 184883
The goal of this sugar node is to be able to look at an arbitrary
FunctionType and tell if any of the parameters were decayed from an
array or function type. Ultimately this is necessary to implement
Microsoft's C++ name mangling scheme, which mangles decayed arrays
differently from normal pointers.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1014
llvm-svn: 184763
Itanium destroys them in the caller at the end of the full expression,
but MSVC destroys them in the callee. This is further complicated by
the need to emit EH-only destructor cleanups in the caller.
This should help clang compile MSVC's debug iterators more correctly.
There is still an outstanding issue in PR5064 of a memcpy emitted by the
LLVM backend, which is not correct for C++ records.
Fixes PR16226.
Reviewers: rjmccall
Differential Revision: http://llvm-reviews.chandlerc.com/D929
llvm-svn: 184543
return false;
in a function returning a pointer. 'false' was a null pointer constant in C++98
but is not in C++11. Punch a very small hole in the initialization rules in
C++11 mode to allow this specific case in system headers.
llvm-svn: 184395
by ensuring DiagnoseUseOfDecl is called both on the found decl and the
decl being used (i.e the specialization in the case of member templates) whenever they are different.
Per the exchange captured in
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130610/081636.html
a more comprehensive fix that allows both decls to be passed into DiagnoseUseOfDecl is (or should be) forthcoming relatively soon.
llvm-svn: 184043
Previously, it only ever fired for zeros which formed null pointers.
Now, hilariously, in C++98 this was almost anything. Including tricks
like warning on the divisor in this code:
typedef char c3[3];
size_t f(c3* ptr) {
return (sizeof(ptr) / sizeof(*ptr)) / (size_t)(!(sizeof(ptr) % sizeof(*ptr)));
}
Why the RHS of the outer divide is a null pointer constant is a sordid
tale of sorrow. Anyways, the committee fixed this for C++11 and onward
as part of core isssue 903, and Richard recently implemented this fix
causing the warning to go away here (and elsewhere).
This patch restores the warning here and adds it for numerous other
somewhat obvious gaffes:
int g(int x) {
return x / (int)(0.0);
}
The patch is essentially just using the full power of our constant
folding in Clang to produce the warning, but insisting that it must fold
to an *integer* which is zero so that we don't get false positives
anywhere.
llvm-svn: 183970
implicit definition of a copy operation is deprecated. Add a warning for this
to -Wdeprecated. This warning is disabled by default for now, pending
investigation into how common this situation is.
llvm-svn: 183884
Timur Iskhodzhanov