since we have absolutely no way to match them when they are declared
nor do we have a way to represent these parsed-but-not-checked friend
declarations.
llvm-svn: 99407
template <> friend void foo(int);
we need to change it to
friend void foo<>(int);
or else the user won't get the template specialization they obviously want.
llvm-svn: 99390
that was present in a prior declaration, emit a warning rather than a
hard error (which we did before, and still do with mismatched
exception specifications). Moreover, provide a fix-it hint with the
throw() clause that should be added, e.g.,
t.C:10:7: warning: 'operator new' is missing exception specification
'throw(std::bad_alloc)'
void *operator new(unsigned long sz)
^
throw(std::bad_alloc)
As part of this, disable the warning when we're missing an exception
specification on operator new, operator new[], operator delete, or
operator delete[] when exceptions are turned off (-fno-exceptions).
Fixes PR5957.
llvm-svn: 99388
templates. So delay access-control diagnostics when (for example) the target
of a friend declaration is a specific specialization of a template.
I was surprised to find that this was required for an access-controlled selfhost.
llvm-svn: 99383
each namespace, even when the outer namespace has multiple
definitions. As part of this, collapsed two pointers worth of storage
(original namespace and inner anonymous namespace) into a single
pointer with a distinguishing bit, since the two are mutually
exclusive, saving a pointer per NamespaceDecl. Fixes PR6620.
llvm-svn: 99368
function within a class hierarchy (C++ [class.virtual]p2).
We use the final-overrider computation to determine when a particular
class is ill-formed because it has multiple final overriders for a
given virtual function (e.g., because two virtual functions override
the same virtual function in the same virtual base class). Fixes
PR5973.
We also use the final-overrider computation to determine which virtual
member functions are pure when determining whether a class is
abstract or diagnosing the improper use of an abstract class. The
prior approach to determining whether there were any pure virtual
functions in a class didn't cope with virtual base class subobjects
properly, and could not easily be fixed to deal with the oddities of
subobject hiding. Fixes PR6631.
llvm-svn: 99351
-disable-free. Among other things, this fixes freeing of the LLVM module on
exit.
- Note that this means we are disable-free'ing of a lot more stuff than we used to -- this should flush out bugs in anything left that is trying to do real work in its destructor. I did a mini-audit but '::~' is not totally uncommon.
llvm-svn: 99258
implementation or synthesized into an implementation. Also,
fixes a code gen. bug when ivars are itroduced in interleaved
implementations. (related to radar 7547942).
llvm-svn: 99193
Diagnostic subsystem, which is used in the rare case where we find a
serious problem (i.e., an inconsistency in the file system) while
we're busy formatting another diagnostic. In this case, the delayed
diagnostic will be emitted after we're done with the other
diagnostic. This is only to be used for fatal conditions detected at
very inconvenient times, where we can neither stop the current
diagnostic in flight nor can we suppress the second error.
llvm-svn: 99175
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
CXXExprWithTemporaries.
Not emitting the expression as an aggregate might be the right thing to do,
but is orthogonal. Emitting it as an scalar expression will still try to
create a temporary for the incomplete type of the CXXExprWithTemporaries and
fail.
llvm-svn: 99134
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
We were inserting a value into a std::vector<> while iterating over
it, which could cause the underlying memory to get deallocated
and reallocated. While not the best solution, use an llvm::ImmutableList
for now as it is safely supports insertions during iteration.
llvm-svn: 99058
expression computation in the wrong bit-width, and end up generating a totally
bogus array reference (_g0+8589934546).
- This showed up on Prolangs/cdecl.
llvm-svn: 99042
preprocessed entities by grouping preprocessed entities by file
ID. This drastically improves performance of repeated
clang_getCursor() calls local tests, although it is a bit ugly.
llvm-svn: 99015
shadowing it in the GlobalDeclMap. Eliminates the string-uniquing
requirement for mangled names, which should help C++ codegen times a little.
Forces us to do string lookups instead of pointer lookups, which might hurt
codegen times a little across the board. We'll see how it plays out.
Removing the string-uniquing requirement implicitly fixes any bugs like
PR6635 which arose from the fact that we had multiple uniquing tables for
different kinds of identifiers.
llvm-svn: 99012
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
instantiations when we have the corresponding macro definition and by
removing macro definition information from our table when the macro is
undefined.
llvm-svn: 99004
record (which includes all macro instantiations and definitions). As
with all lay deserialization, this introduces a new external source
(here, an external preprocessing record source) that loads all of the
preprocessed entities prior to iterating over the entities.
The preprocessing record is an optional part of the precompiled header
that is disabled by default (enabled with
-detailed-preprocessing-record). When the preprocessor given to the
PCH writer has a preprocessing record, that record is written into the
PCH file. When the PCH reader is given a PCH file that contains a
preprocessing record, it will be lazily loaded (which, effectively,
implicitly adds -detailed-preprocessing-record). This is the first
case where we have sections of the precompiled header that are
added/removed based on a compilation flag, which is
unfortunate. However, this data consumes ~550k in the PCH file for
Cocoa.h (out of ~9.9MB), and there is a non-trivial cost to gathering
this detailed preprocessing information, so it's too expensive to turn
on by default. In the future, we should investigate a better encoding
of this information.
llvm-svn: 99002
eliminating the extra PopulatePreprocessingRecord object. This will
become useful once we start writing the preprocessing record to
precompiled headers.
llvm-svn: 98966
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
deserialization of precompiled headers, where the deserialization of
the source location entry for a buffer (e.g., macro instantiation
scratch space) would overwrite a one-element FileID cache in the
source manager. When tickled at the wrong time, we would return the
wrong decomposed source location and eventually cause c-index-test to
crash.
Found by dumb luck. It's amazing this hasn't shown up before.
llvm-svn: 98940
definitions) as part of the translation unit, so that normal
visitation, token-annotation, and cursor-at retrieval all see
preprocessing elements.
llvm-svn: 98935
definitions) as part of the translation unit, so that normal
visitation, token-annotation, and cursor-at retrieval all see
preprocessing elements.
llvm-svn: 98907
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
preprocessing record. Use that link with clang_getCursorReferenced()
and clang_getCursorDefinition() to match instantiations of a macro to
the definition of the macro.
llvm-svn: 98842
the macro definitions and macro instantiations that are found
during preprocessing. Preprocessing records are *not* generated by
default; rather, we provide a PPCallbacks subclass that hooks into the
existing callback mechanism to record this activity.
The only client of preprocessing records is CIndex, which keeps track
of macro definitions and instantations so that they can be exposed via
cursors. At present, only token annotation uses these facilities, and
only for macro instantiations; both will change in the near
future. However, with this change, token annotation properly annotates
macro instantiations that do not produce any tokens and instantiations
of macros that are later undef'd, improving our consistency.
Preprocessing directives that are not macro definitions are still
handled by clang_annotateTokens() via re-lexing, so that we don't have
to track every preprocessing directive in the preprocessing record.
Performance impact of preprocessing records is still TBD, although it
is limited to CIndex and therefore out of the path of the main compiler.
llvm-svn: 98836
Douglas Gregor