Sema needs to be able to accurately determine what will be
emitted as a constant initializer and what will not, so
we get accurate errors in C and accurate -Wglobal-constructors
warnings in C++. This makes Expr::isConstantInitializer match
CGExprConstant as closely as possible.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186464 91177308-0d34-0410-b5e6-96231b3b80d8
This adds three overloaded intrinsics to Clang:
T __builtin_arm_ldrex(const volatile T *addr)
int __builtin_arm_strex(T val, volatile T *addr)
void __builtin_arm_clrex()
The intent is that these do what users would expect when given most sensible
types. Currently, "sensible" translates to ints, floats and pointers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186394 91177308-0d34-0410-b5e6-96231b3b80d8
Not completely sure this is right, but it's clearly better than what
we did before this commit (effectively dropping the attribute).
<rdar://problem/14413117>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186373 91177308-0d34-0410-b5e6-96231b3b80d8
Make sure we call BuildFieldReferenceExpr with the appropriate decl
when a member of an anonymous union is made public with a using decl.
Also, fix a crash on invalid field access into an anonymous union.
Fixes PR16630.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186367 91177308-0d34-0410-b5e6-96231b3b80d8
recovery is not attempted with the fixit. Also move the associated test
case from FixIt/fixit.cpp to SemaCXX/member-expr.cpp since the fixit is
no longer automatically applied.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186342 91177308-0d34-0410-b5e6-96231b3b80d8
This breaks the build of basic patterns with repeated friend
declarations. See the added test case in SemaCXX/friend.cpp or the test
case reported to the original commit log.
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186331 91177308-0d34-0410-b5e6-96231b3b80d8
global allocation or deallocation function, that should not cause that global
allocation or deallocation function to become unavailable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186270 91177308-0d34-0410-b5e6-96231b3b80d8
This simplifies the core benefit of -flimit-debug-info by taking a more
systematic approach to avoid emitting debug info definitions for types
that only require declarations. The previous ad-hoc approach (3 cases
removed in this patch) had many holes.
The general approach (adding a bit to TagDecl and callback through
ASTConsumer) has been discussed with Richard Smith - though always open
to revision.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186262 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186199 91177308-0d34-0410-b5e6-96231b3b80d8
fix is.
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186185 91177308-0d34-0410-b5e6-96231b3b80d8
Make sure we don't crash when checking whether an assignment operator
without any arguments is a special member. <rdar://problem/14397774>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186137 91177308-0d34-0410-b5e6-96231b3b80d8
result type, a diagnostic being issued, issue a 'note'
mentioning reason behind the unexpected warning.
// rdar://14121570.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186105 91177308-0d34-0410-b5e6-96231b3b80d8
& operator (ignoring any overloaded operator& for the type). The purpose of
this builtin is for use in std::addressof, to allow it to be made constexpr;
the existing implementation technique (reinterpret_cast to some reference type,
take address, reinterpert_cast back) does not permit this because
reinterpret_cast between reference types is not permitted in a constant
expression in C++11 onwards.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186053 91177308-0d34-0410-b5e6-96231b3b80d8
lookup in the surrounding context. Slightly rework how we handle friend
declarations to inherit the visibility of the prior declaration, rather
than setting a friend declaration to be visible whenever there was a prior
declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186040 91177308-0d34-0410-b5e6-96231b3b80d8
Compute mangling numbers for externally visible local variables and tags.
Change the mangler to consistently use discriminators where necessary.
Tweak the scheme we use to number decls which are not externally visible
to avoid unnecessary discriminators in common cases now that we request
them more consistently.
Fixes <rdar://problem/14204721>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185986 91177308-0d34-0410-b5e6-96231b3b80d8
method declaration into its implementation to
prevent a bogus warning about mismatched attributes.
then make sure the warning about missing call to super comes out
of the method implementation. // rdar://14251387
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185974 91177308-0d34-0410-b5e6-96231b3b80d8
Combined with typo correction's new ability to apply global/absolute nested
name specifiers to possible corrections, cases such as in PR12287 where the
desired function is being shadowed by a lexically closer function with the
same name but a different number of parameters will now include a FixIt.
On a side note, since the test for this change caused
test/SemaCXX/typo-correction.cpp to exceed the typo correction limit for
a single file, I've included a test case for exceeding the limit and added
some comments to both the original and part two of typo-correction.cpp
warning future editors of the files about the limit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185881 91177308-0d34-0410-b5e6-96231b3b80d8
Use UsualArithmeticConversions unconditionally in analysis of
comparisons and conditional operators: the method performs
the usual arithmetic conversions if both sides are arithmetic, and
usual unary conversions if they are not. This is just a cleanup
for conditional operators; for comparisons, it fixes the issue that
we would try to check isArithmetic() on an atomic type.
Also, fix GetExprRange() in SemaChecking.cpp so it deals with variables
of atomic type correctly.
Fixes PR15537.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185857 91177308-0d34-0410-b5e6-96231b3b80d8
Sema::MergeFunctionDecl attempts merging two decls even if the old decl
is invalid. This can lead to interesting circumstances where we
successfully merge the decls but the result makes no sense.
Take the following for example:
template <typename T>
int main(void);
int main(void);
Sema will not consider these to be overloads of the same name because
main can't be overloaded, which means that this must be a redeclaration.
In this case the templated decl is compatible with the non-templated
decl allowing the Sema::CheckFunctionDeclaration machinery to move on
and do bizarre things like setting the previous decl of a non-templated
decl to a templated decl!
The way I see it, we should just bail from MergeFunctionDecl if the old
decl is invalid.
This fixes PR16531.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185779 91177308-0d34-0410-b5e6-96231b3b80d8
This boils down to us sending invalid function decls to
CheckFunctionDeclaration becauswe we did not consider that CheckMain
could cause the decl to be invalid. Instead, interogate the new decl's
main-validity and *then* send it over to get CheckFunctionDeclaration'd
if it was still valid after calling CheckMain.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185745 91177308-0d34-0410-b5e6-96231b3b80d8
Jean-Daniel Dupas