When a local extern declaration redeclares some other entity, the type of that
entity is merged with the prior type if the prior declaration is visible (in C)
or is declared in the same scope (in C++).
- Make LookupRedeclarationWithLinkage actually work in C++, use it in the right
set of cases, and make it track whether it found a shadowed declaration.
- Track whether we found a declaration in the same scope (for C++) including
across serialization and template instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188307 91177308-0d34-0410-b5e6-96231b3b80d8
I'm not really satisfied with the ad-hoc nature of
Sema::diagnoseQualifiedDeclaration, but I'm not sure how to fix it.
Fixes <rdar://problem/14639501>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188208 91177308-0d34-0410-b5e6-96231b3b80d8
of local classes. We were previously handling this by performing qualified
lookup within a function declaration(!!); replace it with the proper scope
lookup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188050 91177308-0d34-0410-b5e6-96231b3b80d8
bool, half, pointers and structs / unions containing any
of these are not allowed. Does not yet reject size_t and
related integer types that are also disallowed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186908 91177308-0d34-0410-b5e6-96231b3b80d8
The functionality is equivalent to the GCC attribute. Variables of tagged
types will be warned about as unused if they are not used in any way
except for possible (even non-trivial) ctors/dtors called. Useful for tagging
classes like std::string (which is not part of this commit).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186765 91177308-0d34-0410-b5e6-96231b3b80d8
r186331).
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@186546 91177308-0d34-0410-b5e6-96231b3b80d8
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
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
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
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
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
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
The removal is tried by retrying the failed lookup of a correction
candidate with either the MemberContext or SS (CXXScopeSpecifier) or
both set to NULL if they weren't already. If the candidate identifier
is then looked up successfully, make a note in the candidate that the
SourceRange should include any existing nested name specifier even if
the candidate isn't adding a different one (i.e. the candidate has a
NULL NestedNameSpecifier).
Also tweak the diagnostic messages to differentiate between a suggestion
that just replaces the identifer but leaves the existing nested name
specifier intact and one that replaces the entire qualified identifier,
in cases where the suggested replacement is unqualified.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185487 91177308-0d34-0410-b5e6-96231b3b80d8
standard's rule that an extern "C" declaration conflicts with any entity in the
global scope with the same name. Now we only care if the global scope entity is
a variable declaration (and so might have the same mangled name as the extern
"C" declaration). This has been reported as a standard defect.
Original commit message:
PR7927, PR16247: Reimplement handling of matching extern "C" declarations
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185281 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185229 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185100 91177308-0d34-0410-b5e6-96231b3b80d8
Make use of getTypeSizeInChars to detect structs/unions of zero size. It allows
more accurate detection of types of zero size. It however has a side effect -
sequence of used types may change, that is why the test 'override-layout' was
modified.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184088 91177308-0d34-0410-b5e6-96231b3b80d8
random checks for ObjC object return types to SemaType.cpp.
Fixes issue with ObjC method type checking reported on cfe-dev.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184006 91177308-0d34-0410-b5e6-96231b3b80d8
__clear_cache is special. It needs no signature, but is a real function in
compiler_rt or libgcc.
Patch by Andrew Turner.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183926 91177308-0d34-0410-b5e6-96231b3b80d8
Disallow the existence of a declaration of a member class that isn't a
forward declaration before it's definition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183722 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r183614.
It broke test/Sema/block-printf-attribute-1.c on non-Windows platforms,
and the fix is not trivial.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183616 91177308-0d34-0410-b5e6-96231b3b80d8
This helps preserve the type-as-written in the AST, which we need for
MSVC mangling. In particular, we need to preserve the types of array
parameters in function pointer types.
The essence of this change is:
- QualType ArgTy = Param->getType();
+ QualType ArgTy = Param->getTypeSourceInfo()->getType();
... followed by the adjustment in ActOnFunctionDeclarator().
Differential Revision: http://llvm-reviews.chandlerc.com/D883
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183614 91177308-0d34-0410-b5e6-96231b3b80d8
references. What's more, they use this language extension in their
ATL header files (which come as part of MFC and the Win32 SDK). This patch implements support for the Microsoft extension, and addresses PR13737.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182936 91177308-0d34-0410-b5e6-96231b3b80d8
C++ and C differ with respect to the handling of extern void
declarations. Enforce the C++ behavior in C++ mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182814 91177308-0d34-0410-b5e6-96231b3b80d8
While the C++ standard requires that this lookup take place only at the
definition point of a virtual destructor (C++11 [class.dtor]p12), the
Microsoft ABI may require the compiler to emit a deleting destructor
for any virtual destructor declared in the TU, including ones without
a body, requiring an operator delete() lookup for every virtual
destructor declaration. The result of the lookup should be the same
no matter which declaration is used (except in weird corner cases).
This change will cause us to reject some valid TUs in Microsoft ABI
mode, e.g.:
struct A {
void operator delete(void *);
};
struct B {
void operator delete(void *);
};
struct C : A, B {
virtual ~C();
};
As Richard points out, every virtual function declared in a TU
(including this virtual destructor) is odr-used, so it must be defined
in any program which declares it, or the program is ill formed, no
diagnostic required. Because we know that any definition of this
destructor will cause the lookup to fail, the compiler can choose to
issue a diagnostic here.
Differential Revision: http://llvm-reviews.chandlerc.com/D822
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182270 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith