| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
| 
| 
|  | 
longer needed now that we aren't back-patching ObjCProtocolDecls.
llvm-svn: 147413
 | 
| | 
| 
| 
| 
| 
| 
|  | 
forward declarations and definitions of an Objective-C protocol are
represented within a single chain of ObjCProtocolDecls.
llvm-svn: 147412
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
for Objective-C protocols, including:
  - Using the first declaration as the canonical declaration
  - Using the definition as the primary DeclContext
  - Making sure that all declarations have a pointer to the definition
  data, and that we know which declaration is the definition
  - Serialization support for redeclaration chains and for adding
  definitions to already-serialized declarations.
However, note that we're not taking advantage of much of this code
yet, because we're still re-using ObjCProtocolDecls.
llvm-svn: 147410
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
separately-allocated DefinitionData structure. Introduce various
functions that will help with the separation of declarations from
definitions (isThisDeclarationADefinition(), hasDefinition(),
getDefinition()).
llvm-svn: 147408
 | 
| | 
| 
| 
|  | 
llvm-svn: 147407
 | 
| | 
| 
| 
| 
| 
| 
|  | 
'is an extension'. The former is inappropriate and confusing when building with
-Werror/-pedantic-errors.
llvm-svn: 147357
 | 
| | 
| 
| 
| 
| 
|  | 
clients. No functionality change.
llvm-svn: 147318
 | 
| | 
| 
| 
| 
| 
| 
|  | 
covers both declarations (@class) and definitions (@interface) of an
Objective-C class.
llvm-svn: 147299
 | 
| | 
| 
| 
|  | 
llvm-svn: 147281
 | 
| | 
| 
| 
| 
| 
| 
|  | 
longer have access to the source locations we need to produce the
'replace constexpr with const' fixits, so they're gone for now.
llvm-svn: 147273
 | 
| | 
| 
| 
|  | 
llvm-svn: 147260
 | 
| | 
| 
| 
| 
| 
| 
|  | 
case they override virtual functions from a base class. Also fix -print-stats
counting of move assignment/construction.
llvm-svn: 147258
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Explicit instantiations following specializations are no-ops and hence have
no PointOfInstantiation. That was done correctly in most cases, but for a
specialization -> instantiation decl -> instantiation definition chain, the
definition didn't realize that it was a no-op. Fix that.
Also, when printing diagnostics for these no-ops, get the diag location from
the decl name location.
Add many test cases, one of them not yet passing (but it failed the same way
before this change). Fixes http://llvm.org/pr11558 and more.
llvm-svn: 147225
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
so this patch is surprisingly small.
Also drop -Wc1x-extensions in favor of -Wc11-extensions. I don't think we need to keep this around for compatibility.
llvm-svn: 147221
 | 
| | 
| 
| 
| 
| 
|  | 
to initialization sequence dumping.
llvm-svn: 147171
 | 
| | 
| 
| 
|  | 
llvm-svn: 147156
 | 
| | 
| 
| 
| 
| 
|  | 
overloading, initializer_list.
llvm-svn: 147145
 | 
| | 
| 
| 
| 
| 
|  | 
definition would satisfy the constexpr requirements.
llvm-svn: 147128
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
- constexpr function template instantiations
 - variables of reference type
 - constexpr variables
llvm-svn: 147031
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
members of class templates so that their values can be used in ICEs. This
required reverting r105465, to get such instantiated members to be included in
serialized ASTs.
llvm-svn: 147023
 | 
| | 
| 
| 
| 
| 
| 
|  | 
on method declaration and definition if former is in
a system header. // rdar://10580333
llvm-svn: 147020
 | 
| | 
| 
| 
| 
| 
|  | 
in class method instead of crash. // rdar://10593227
llvm-svn: 146998
 | 
| | 
| 
| 
|  | 
llvm-svn: 146988
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
visibility restrictions. This ensures that all declarations of the
same entity end up in the same redeclaration chain, even if some of
those declarations aren't visible. While this may seem unfortunate to
some---why can't two C modules have different functions named
'f'?---it's an acknowedgment that a module does not introduce a new
"namespace" of names.
As part of this, stop merging the 'module-private' bit from previous
declarations to later declarations, because we want each declaration
in a module to stand on its own because this can effect, for example,
submodule visibility.
Note that this notion of names that are invisible to normal name
lookup but are available for redeclaration lookups is how we should
implement friend declarations and extern declarations within local
function scopes. I'm not tackling that problem now.
llvm-svn: 146980
 | 
| | 
| 
| 
|  | 
llvm-svn: 146967
 | 
| | 
| 
| 
|  | 
llvm-svn: 146961
 | 
| | 
| 
| 
| 
| 
|  | 
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
llvm-svn: 146959
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Split out a new ExpressionEvaluationContext flag for this case, and don't treat
it as unevaluated in C++11. This fixes some crash-on-invalids where we would
allow references to class members in potentially-evaluated constant expressions
in static member functions, and also fixes half of PR10177.
The fix to PR10177 exposed a case where template instantiation failed to provide
a source location for a diagnostic, so TreeTransform has been tweaked to supply
source locations when transforming a type. The source location is still not very
good, but MarkDeclarationsReferencedInType would need to operate on a TypeLoc to
improve it further.
Also fix MarkDeclarationReferenced in C++98 mode to trigger instantiation for
static data members of class templates which are used in constant expressions.
This fixes a link-time problem, but we still incorrectly treat the member as
non-constant. The rest of the fix for that issue is blocked on PCH support for
early-instantiated static data members, which will be added in a subsequent
patch.
llvm-svn: 146955
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
variable is initialized by a non-constant expression, and pass in the variable
being declared so that earlier-initialized fields' values can be used.
Rearrange VarDecl init evaluation to make this possible, and in so doing fix a
long-standing issue in our C++ constant expression handling, where we would
mishandle cases like:
  extern const int a;
  const int n = a;
  const int a = 5;
  int arr[n];
Here, n is not initialized by a constant expression, so can't be used in an ICE,
even though the initialization expression would be an ICE if it appeared later
in the TU. This requires computing whether the initializer is an ICE eagerly,
and saving that information in PCH files.
llvm-svn: 146856
 | 
| | 
| 
| 
|  | 
llvm-svn: 146847
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
chains. The previous implementation relied heavily on the declaration
chain being stored as a (circular) linked list on disk, as it is in
memory. However, when deserializing from multiple modules, the
different chains could get mixed up, leading to broken declaration chains.
The new solution keeps track of the first and last declarations in the
chain for each module file. When we load a declaration, we search all
of the module files for redeclarations of that declaration, then
splice together all of the lists into a coherent whole (along with any
redeclarations that were actually parsed). 
As a drive-by fix, (de-)serialize the redeclaration chains of
TypedefNameDecls, which had somehow gotten missed previously. Add a
test of this serialization.
This new scheme creates a redeclaration table that is fairly large in
the PCH file (on the order of 400k for Cocoa.h's 12MB PCH file). The
table is mmap'd in and searched via a binary search, but it's still
quite large. A future tweak will eliminate entries for declarations
that have no redeclarations anywhere, and should
drastically reduce the size of this table.
llvm-svn: 146841
 | 
| | 
| 
| 
| 
| 
|  | 
declarations without a declarator to structs.  Add a warning for ignored attributes.  Patch by Michael Han.
llvm-svn: 146796
 | 
| | 
| 
| 
| 
| 
|  | 
initialization that involves a ConstructorConversion
llvm-svn: 146766
 | 
| | 
| 
| 
| 
| 
| 
|  | 
might not be an rvalue when checking array accesses. Instead, pass through a
flag indicating the array index is negated.
llvm-svn: 146753
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
fails within a call to a constexpr function. Add -fconstexpr-backtrace-limit
argument to driver and frontend, to control the maximum number of notes so
produced (default 10). Fix APValue printing to be able to pretty-print all
APValue types, and move the testing for this functionality from a unittest to
a -verify test now that it's visible in clang's output.
llvm-svn: 146749
 | 
| | 
| 
| 
| 
| 
|  | 
Reviewed by Eli Friedman.
llvm-svn: 146738
 | 
| | 
| 
| 
| 
| 
|  | 
on properties, prevent consequential error  diagnostics. // rdar://10591336
llvm-svn: 146737
 | 
| | 
| 
| 
|  | 
llvm-svn: 146722
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
instantiate a class from its template pattern
before it consults the ExternalASTSource.  LLDB
in particular will sometimes provide patterns
that need to be completed first.
To make this possible, I have moved the
completion before the code that does the
instantiation, allowing the ExternalASTSource
to provide the required information.
llvm-svn: 146715
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
applies to an actual definition. Plus, clarify the purpose of this
field and give the accessor a different name, since getLocEnd() is
supposed to be the same as getSourceRange().getEnd().
llvm-svn: 146694
 | 
| | 
| 
| 
| 
| 
|  | 
check whether any previous declarations of the class were visible.
llvm-svn: 146680
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
declarations and definitions) as ObjCInterfaceDecls within the same
redeclaration chain. This new representation matches what we do for
C/C++ variables/functions/classes/templates/etc., and makes it
possible to answer the query "where are all of the declarations of
this class?"
llvm-svn: 146679
 | 
| | 
| 
| 
|  | 
llvm-svn: 146673
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
don't refer to anything. Amusingly, we were relying on this in one
place. Thanks to Chandler for noticing the weirdness in
declaresSameEntity.
llvm-svn: 146659
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
extension.
This fixes gcc.dg/format/c90-scanf-3.c and ext-4.c (test for excess
errors).
llvm-svn: 146649
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
separately-allocated DefinitionData structure, which we manage the
same way as CXXRecordDecl::DefinitionData. This prepares the way for
making ObjCInterfaceDecls redeclarable, to more accurately model
forward declarations of Objective-C classes and eliminate the mutation
of ObjCInterfaceDecl that causes us serious trouble in the AST reader.
Note that ObjCInterfaceDecl's accessors are fairly robust against
being applied to forward declarations, because Clang (and Sema in
particular) doesn't perform RequireCompleteType/hasDefinition() checks
everywhere it has to. Each of these overly-robust cases is marked with
a FIXME, which we can tackle over time.
llvm-svn: 146644
 | 
| | 
| 
| 
| 
| 
|  | 
in the case of a shifted bitfield.  PR11572.
llvm-svn: 146634
 | 
| | 
| 
| 
| 
| 
|  | 
protocols; with a warning. // rdar://10567333
llvm-svn: 146626
 | 
| | 
| 
| 
| 
| 
| 
|  | 
expression with an unknown result type, assume that the result type is
'id'. Fixes <rdar://problem/10400663>.
llvm-svn: 146622
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
to declaresSameEntity(), as a baby step toward tracking forward
declarations of Objective-C classes precisely. Part of
<rdar://problem/10583531>.
llvm-svn: 146618
 |