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
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
redeclaration chain for Objective-C classes, 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 the definition knows that it is the definition.
- Serialization support for when a definition gets added to a
declaration that comes from an AST file.
However, note that we're not taking advantage of much of this code
yet, because we're still re-using ObjCInterfaceDecls.
llvm-svn: 146667
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
that value-initializes all of its members for which
default-initialization does not suffice. This should clean up the
failures for compilers that do not implement C++ DR543:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#543
and, therefore, implement very unfortunate semantics for
value-initialization of classes with implicitly-declared, non-trivial
default constructors.
llvm-svn: 146658
The function TRI::getCommonSubClass(A, B) returns the largest common
sub-class of the register classes A and B. This patch teaches TableGen
to synthesize sub-classes such that the answer is always maximal.
In other words, every register that is in both A and B will also be
present in getCommonSubClass(A, B).
This introduces these synthetic register classes:
ARM:
GPRnopc_and_hGPR
GPRnopc_and_hGPR
hGPR_and_rGPR
GPRnopc_and_hGPR
GPRnopc_and_hGPR
hGPR_and_rGPR
tGPR_and_tcGPR
hGPR_and_tcGPR
X86:
GR32_NOAX_and_GR32_NOSP
GR32_NOAX_and_GR32_NOREX
GR64_NOSP_and_GR64_TC
GR64_NOSP_and_GR64_TC
GR64_NOREX_and_GR64_TC
GR32_NOAX_and_GR32_NOSP
GR32_NOAX_and_GR32_NOREX
GR32_NOAX_and_GR32_NOREX_NOSP
GR64_NOSP_and_GR64_TC
GR64_NOREX_and_GR64_TC
GR64_NOREX_NOSP_and_GR64_TC
GR32_NOAX_and_GR32_NOSP
GR32_NOAX_and_GR32_NOREX
GR32_NOAX_and_GR32_NOREX_NOSP
GR32_ABCD_and_GR32_NOAX
GR32_NOAX_and_GR32_NOSP
GR32_NOAX_and_GR32_NOREX
GR32_NOAX_and_GR32_NOREX_NOSP
GR32_ABCD_and_GR32_NOAX
GR32_NOAX_and_GR32_TC
GR32_NOAX_and_GR32_NOSP
GR64_NOSP_and_GR64_TC
GR32_NOAX_and_GR32_NOREX
GR32_NOAX_and_GR32_NOREX_NOSP
GR64_NOREX_and_GR64_TC
GR64_NOREX_NOSP_and_GR64_TC
GR32_ABCD_and_GR32_NOAX
GR64_ABCD_and_GR64_TC
GR32_NOAX_and_GR32_TC
GR32_AD_and_GR32_NOAX
Other targets are unaffected.
llvm-svn: 146657
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
Kostya Serebryany