TSK_ExplicitInstantiationDeclaration make sure we call
MaybeMarkVirtualMembersReferenced with a method attached to the definition.
Remove the hack that forced vtable emition with declarations.
llvm-svn: 99174
entering a function or block definition, not on every single declaration.
Unfortunately we don't have previous-lookup results around when it's time
to make this decision, so we have to redo the lookup. The alternative is
to use delayed diagnostics.
llvm-svn: 99172
This object controls when the warnings are executed, allowing the client code
in Sema to selectively disable warnings as needed.
Centralizing the logic for analysis-based warnings allows us to optimize
when and how they are run.
Along the way, remove the redundant logic for the 'check fall-through' warning
for blocks; now the same logic is used for both blocks and functions.
llvm-svn: 99085
ranges as part of the ASTContext. This code is not and was never used,
but contributes ~250k to the size of the Cocoa.h precompiled
header.
llvm-svn: 99007
entity (if applicable) which was actually looked up. If a candidate was found
via a using declaration, this is the UsingShadowDecl; otherwise, if
the candidate is template specialization, this is the template; otherwise,
this is the function.
The point of this exercise is that "found declarations" are the entities
we do access control for, not their underlying declarations. Broadly speaking,
this patch fixes access control for using declarations.
There is a *lot* of redundant code calling into the overload-resolution APIs;
we really ought to clean that up.
llvm-svn: 98945
access to the (elevated) access of the accessed declaration, if applicable,
rather than plunking that access onto the end after we've calculated the
inheritance access.
Also, being a friend of a derived class gives you public access to its
members (subject to later modification by further inheritance); it does
not simply ignore a single location of restricted inheritance.
Also, when computing the best unprivileged path to a subobject, preserve
the information that the worst path might be AS_none (forbidden) rather
than a minimum of AS_private.
llvm-svn: 98899
non-placement news when selecting the corresponding operator delete; this is
fixed.
Access and ambiguity control for calls to operator new and delete. Also AFAICT
llvm-svn: 98818
ActOnStartCXXMemberDeclaration. We haven't started the field collector on this
class yet, so don't stop it. Fixes a crash in the VS buildbot and a memory error
on all the others.
llvm-svn: 98760
SourceManager's getBuffer() (and similar) operations. This abstract
can be used to force callers to cope with errors in getBuffer(), such
as missing files and changed files. Fix a bunch of callers to use the
new interface.
Add some very basic checks for file consistency (file size,
modification time) into ContentCache::getBuffer(), although these
checks don't help much until we've updated the main callers (e.g.,
SourceManager::getSpelling()).
llvm-svn: 98585
parameter hides a namespace-scope declararion with the same name in an
out-of-line definition of a template. The lookup requires a strange
interleaving of lexical and semantic scopes (go C++), which I have not
yet handled in the typo correction/code completion path.
Fixes PR6594.
llvm-svn: 98544
on unqualified declarations.
Patch by Enea Zaffanella! Minimal adjustments: allocate the ExtInfo nodes
with the ASTContext and delete them during Destroy(). I audited a bunch of
Destroy methods at the same time, to ensure that the correct teardown was
being done.
llvm-svn: 98540
the @implementation (instead of the @interface) and actually add
the ivar to the DeclContext (which we weren't doing before).
This allows us to simplify ASTContext::CollectNonClassIvars() by
removing ASTContext::CollectProtocolSynthesizedIvars(). Now all
ivars can be found by either inspecting the ObjCInterfaceDecl and
its companion ObjCImplementationDecl.
llvm-svn: 98280
instantiation. Based on a patch by Enea Zaffanella! I found a way to
reduce some of the redundancy between TreeTransform's "standard"
FunctionProtoType transformation and TemplateInstantiator's override,
and I killed off the old SubstFunctionType by adding type source info
for the last cases where we were creating FunctionDecls without TSI
(at least that get passed through template instantiation).
llvm-svn: 98252
I'm expecting this portion of the AST to grow and change, and I'd like to
be able to do that with minimal recompilation. If this proves unnecessary
when access control is fully-implemented, I'll fold the classes back into
DeclCXX.h.
llvm-svn: 98249
injected class name of a class template or class template partial specialization.
This is a non-canonical type; the canonical type is still a template
specialization type. This becomes the TypeForDecl of the pattern declaration,
which cleans up some amount of code (and complicates some other parts, but
whatever).
Fixes PR6326 and probably a few others, primarily by re-establishing a few
invariants about TypeLoc sizes.
llvm-svn: 98134
uninitialized. This seems not to be the case in C++0x, where we still
call the (trivial) default constructor for a POD class
(!). Previously, we had implemented only the C++0x rules; now we
implement both. Fixes PR6536.
llvm-svn: 97928
nested-name-specifier. For example, this allows member access in
diamond-shaped hierarchies like:
struct Base {
void Foo();
int Member;
};
struct D1 : public Base {};
struct D2 : public Base {};
struct Derived : public D1, public D2 { }
void Test(Derived d) {
d.Member = 17; // error: ambiguous cast from Derived to Base
d.D1::Member = 17; // error: okay, modify D1's Base's Member
}
Fixes PR5820 and <rdar://problem/7535045>. Also, eliminate some
redundancy between Sema::PerformObjectMemberConversion() and
Sema::PerformObjectArgumentInitialization() -- the latter now calls
the former.
llvm-svn: 97674
declarations after the member has been explicitly specialized. We already
did this after explicit instantiation definitions; not doing it for
declarations meant that subsequent definitions would see a previous
member declaration with specialization kind "explicit instantiation decl",
which would then happily get overridden.
Fixes PR 6458.
llvm-svn: 97605
used to do this, but it got lost when we switched functional-style
cast syntax over to using the new initialization code. Fixes PR6457.
llvm-svn: 97568
category. Use this in a few places to eliminate unnecessary TST cases and
do some future-proofing. Provide terrible manglings for typeof. Mangle
decltype with some hope of accuracy.
Our manglings for some of the cases covered in the testcase are different
from gcc's, which I've raised as an issue with the ABI list.
llvm-svn: 97523
which has the label map, switch statement stack, etc. Previously, we
had a single set of maps in Sema (for the function) along with a stack
of block scopes. However, this lead to funky behavior with nested
functions, e.g., in the member functions of local classes.
The explicit-stack approach is far cleaner, and we retain a 1-element
cache so that we're not malloc/free'ing every time we enter a
function. Fixes PR6382.
Also, tweaked the unused-variable warning suppression logic to look at
errors within a given Scope rather than within a given function. The
prior code wasn't looking at the right number-of-errors count when
dealing with blocks, since the block's count would be deallocated
before we got to ActOnPopScope. This approach works with nested
blocks/functions, and gives tighter error recovery.
llvm-svn: 97518
re-declare them. This fixes PR6317. Also add the beginnings of an interesting
test case for p1 of [class.friend] which also covers PR6317.
llvm-svn: 97499
a fixme and PR6451.
Only perform jump checking if the containing function has no errors,
and add the infrastructure needed to do this.
On the testcase in the PR, we produce:
t.cc:6:3: error: illegal goto into protected scope
goto later;
^
t.cc:7:5: note: jump bypasses variable initialization
X x;
^
llvm-svn: 97497
template definition. Do this both by being more tolerant of errors in
our asserts and by not dropping a variable declaration completely when
its initializer is ill-formed. Fixes the crash-on-invalid in PR6375,
but not the original issue.
llvm-svn: 97463
larger unsigned value, since this is implementation-defined
behavior. (We previously suppressed this warning when converting from
a signed value to an unsigned value of the same size).
llvm-svn: 97430
Sema and into analyze_printf::ParseFormatString(). Also use a bitvector to determine
what arguments have been covered (instead of just checking to see if the last argument consumed is the max argument). This is prep. for support positional arguments (an IEEE extension).
llvm-svn: 97248
how we find the operator delete that matches withe operator new we
found in a C++ new-expression.
This will also need CodeGen support. On a happy note, we're now a
"nans" away from building tramp3d-v4.
llvm-svn: 97209
used when we instantiate C++ new expressions, delete expressions, and
object-construction expressions. Fixes PR6424, although we can't test
all of it until we finish implementing lookup of "operator delete" for
new expressions (!).
llvm-svn: 97195
to mark the constructor as referenced. Fixes the narrow issue reported
in PR6424, but there are a few other places that I'll fix before
closing out that PR.
llvm-svn: 97185
equality comparisons, and conditional operators, produce a composite
pointer type with the appropriate additional "const" qualifiers if the
pointer types would otherwise be incompatible. This is a small
extension (also present in GCC and EDG in a slightly different form)
that permits code like:
void** i; void const** j;
i == j;
with the following extwarn:
t.cpp:5:5: warning: comparison of distinct pointer types ('void **' and
'void const **') uses non-standard composite pointer type
'void const *const *' [-pedantic]
i == j;
~ ^ ~
Fixes PR6346, and I'll be filing a core issue about this with the C++
committee.
llvm-svn: 97177
compilation using g++ v3.4.
I'll watch the buildbots and back out if necessary.
Feel free to do the same if something breaks.
Without this patch I get (on g++ 3.4.6) following error:
In file included from clang/lib/Sema/SemaTemplate.cpp:14:
clang/lib/Sema/TreeTransform.h: In member function `clang::ASTOwningResult<&clang::ActionBase::DeleteExpr> clang::TreeTransform<Derived>::RebuildCXXPseudoDestructorExpr(clang::ASTOwningResult<&clang::ActionBase::DeleteExpr>, clang::SourceLocation, bool, clang::NestedNameSpecifier*, clang::SourceRange, clang::TypeSourceInfo*, clang::SourceLocation, clang::SourceLocation, clang::PseudoDestructorTypeStorage)':
clang/lib/Sema/TreeTransform.h:5784: error: expected primary-expression before '>' token
clang/lib/Sema/TreeTransform.h:5784: error: expected primary-expression before ')' token
make[4]: *** [clang/lib/Sema/Release/SemaTemplate.o] Error 1
llvm-svn: 97136
skip the object argument conversion if either of the candidates didn't
initialize it.
Fixes PR6421, which is such a very straightforward extension of PR6398 that I
should have worked it into the last test case (and therefore caught it then).
Ah well.
llvm-svn: 97135
types. Rank these conversions below other conversions. This allows overload
resolution when the only distinction is between a complex and scalar type. It
also brings the complex overload resolutin in line with GCC's.
llvm-svn: 97128
class types, dependent types, and namespaces. I had previously
weakened this invariant while working on parsing pseudo-destructor
expressions, but recent work in that area has made these changes
unnecessary.
llvm-svn: 97112
expressions that look like pseudo-destructors, e.g.,
p->T::~T()
where p has dependent type.
At template instantiate time, we determine whether we actually have a
pseudo-destructor or a member access, and funnel down to the
appropriate routine in Sema.
Fixes PR6380.
llvm-svn: 97092
CXXPseudoDestructorExpr.
Update template instantiation for pseudo-destructor expressions to use
this source information and to make use of
Sema::BuildPseudoDestructorExpr when the base expression is dependent
or refers to a scalar type.
llvm-svn: 97079
parser's data structures and the part that performs semantic analysis
and AST building, in preparation for improved template instantiation
of pseudo-destructor expressions.
llvm-svn: 97070
pseudo-destructor expressions, and builds the CXXPseudoDestructorExpr
node directly. Currently, this only affects pseudo-destructor
expressions when they are parsed, but not after template
instantiation. That's coming next...
Improve parsing of pseudo-destructor-names. When parsing the
nested-name-specifier and we hit the sequence of tokens X :: ~, query
the actual module to determine whether X is a type-name (in which case
the X :: is part of the pseudo-destructor-name but not the
nested-name-specifier) or not (in which case the X :: is part of the
nested-name-specifier).
llvm-svn: 97058
destructor calls, e.g.,
p->T::~T
We now detect when the member access that we've parsed, e.g.,
p-> or x.
may be a pseudo-destructor expression, either because the type of p or
x is a scalar or because it is dependent (and, therefore, may become a
scalar at template instantiation time).
We then parse the pseudo-destructor grammar specifically:
::[opt] nested-name-specifier[opt] type-name :: ∼ type-name
and hand those results to a new action, ActOnPseudoDestructorExpr,
which will cope with both dependent member accesses of destructors and
with pseudo-destructor expressions.
This commit affects the parsing of pseudo-destructors, only; the
semantic actions still go through the semantic actions for member
access expressions. That will change soon.
llvm-svn: 97045
C++98/03 and C++0x, since the '0x semantics break valid C++98/03
code. This new mess is tracked by core issue 399, which is still
unresolved.
Fixes PR6358 and PR6359.
llvm-svn: 96836
errors, e.g.:
t.c:1:21: error: redefinition of parameter 'x'
int test(int x, int x);
^
t.c:1:14: note: previous declaration is here
int test(int x, int x);
^
llvm-svn: 96769
fixing up a few callers that thought they were propagating NoReturn
information but were in fact saying something about exception
specifications.
llvm-svn: 96766
typedef int Int;
int *p;
p->Int::~Int();
This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression.
llvm-svn: 96743
figure out how not to break lots of code using this. See PR6358 and PR6359 for
motivating examples. FIXME's left in the code and the test.
llvm-svn: 96733
are for out of line declarations more easily. This simplifies the logic and
handles the case of out-of-line class definitions correctly. Fixes PR6107.
llvm-svn: 96729
instead it crashes on them. We might extend this attribute to work on methods, but for
now fix the crasher. Addresses <rdar://problem/7670939>.
llvm-svn: 96723
from an instance method. Previously, we were following the Objective-C
name lookup rules for ivars, which are of course completely different
from and incompatible with the Objective-C++ rules.
For the record, the Objective-C++ rules are the sane ones.
This is another part of <rdar://problem/7660386>.
llvm-svn: 96677
to initializer expressions in an array allocated using ASTContext.
This plugs a memory leak when ASTContext uses a BumpPtrAllocator to
allocate memory for AST nodes.
In my mind this isn't an ideal solution; it would be nice to have
a general "vector"-like class that allocates memory using ASTContext,
but whose guts could be separated from the methods of InitListExpr
itself. I haven't gone and taken this approach yet because it isn't
clear yet if we'll eventually want an alternate solution for recylcing
memory using by InitListExprs as we are constructing the ASTs.
llvm-svn: 96642
which describes temporary objects of class type in C++. Use this to
provide a more-specific, remappable diagnostic when takin the address
of such a temporary.
llvm-svn: 96396
now cope with the destruction of types named as dependent templates,
e.g.,
y->template Y<T>::~Y()
Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't
follow the letter of the standard here because that would fail to
parse
template<typename T, typename U>
X0<T, U>::~X0() { }
properly. The problem is captured in core issue 339, which gives some
(but not enough!) guidance. I expect to revisit this code when the
resolution of 339 is clear, and/or we start capturing better source
information for DeclarationNames.
Fixes PR6152.
llvm-svn: 96367
those declared in it. This is to allow duplicate
property diagnostics for properties declared in class extensions
multiple times (radar 7629420) and for future use.
llvm-svn: 96276
Rafael Espindola