|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| | be different for the same overrider in different parts of the vtable.
llvm-svn: 97068 | 
| | 
| 
| 
| | llvm-svn: 97067 | 
| | 
| 
| 
| | llvm-svn: 97066 | 
| | 
| 
| 
| 
| 
| 
| 
| | pseudo-destructor expression such as
  p->T::~T()
llvm-svn: 97060 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| 
| | on non-darwin platforms.  Fixes PR6411. Test case doesn't reduce,
unfortunately.
llvm-svn: 97055 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| | not a primary base in the complete class hierarchy.
llvm-svn: 97039 | 
| | 
| 
| 
| 
| 
| | Fixes PR6373.
llvm-svn: 97037 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | a common source of oddities and, in theory, removes some redundant ABI
computations.  Also fixes a miscompile I introduced yesterday by refactoring
some code and causing a slightly different code path to be taken that
didn't perform *parameter* type canonicalization, just normal type
canonicalization;  this in turn caused a bit of ABI code to misfire because
it was looking for 'double' or 'float' but received 'const float'.
llvm-svn: 97030 | 
| | 
| 
| 
| 
| 
| 
| | apply it only to the function itself, and never to the return type. Fixes part
of PR6408.
llvm-svn: 97015 | 
| | 
| 
| 
| 
| 
| | analysis needs this.
llvm-svn: 97014 | 
| | 
| 
| 
| 
| 
| | a block pointer type. Fixes radar 7682149.
llvm-svn: 97008 | 
| | 
| 
| 
| | llvm-svn: 97005 | 
| | 
| 
| 
| | llvm-svn: 97002 | 
| | 
| 
| 
| | llvm-svn: 96999 | 
| | 
| 
| 
| 
| 
| | llvm-gcc does, but are more strict on what uses of weakref we accept.
llvm-svn: 96992 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | of the block descriptor field.  This field is the ObjC style @encode
signature of the implementation function, and was to this point
conditionally provided in the block literal data structure.  That
provisional support is removed.
Additionally, eliminate unused enumerations for the block literal flags field.
The first shipping ABI unconditionally set (1<<29) but this bit is unused
by the runtime, so the second ABI will unconditionally have (1<<30) set so
that the runtime can in fact distinguish whether the additional data is
present or not.
llvm-svn: 96989 | 
| | 
| 
| 
| 
| 
| | rewriting problem. Fixes radar 7680953.
llvm-svn: 96987 | 
| | 
| 
| 
| 
| 
| 
| | pointer (for defensive programming).  This matches the behavior with
assigning NULL to a regular pointer.  Fixes <rdar://problem/7631278>.
llvm-svn: 96985 | 
| | 
| 
| 
| 
| 
| 
| 
| | (with no names)
that refer to an undefined class.
llvm-svn: 96976 | 
| | 
| 
| 
| 
| 
| | the result is integral.  Fixes <rdar://problem/7676608>.
llvm-svn: 96970 | 
| | 
| 
| 
| | llvm-svn: 96962 | 
| | 
| 
| 
| | llvm-svn: 96961 | 
| | 
| 
| 
| | llvm-svn: 96958 | 
| | 
| 
| 
| | llvm-svn: 96941 | 
| | 
| 
| 
| | llvm-svn: 96897 | 
| | 
| 
| 
| 
| 
| 
| | the canonical calling conventions instead of comparing the raw calling
conventions directly. Fixes PR6361.
llvm-svn: 96895 | 
| | 
| 
| 
| 
| 
| | to libAnalysis (with only the error reporting in libSema).
llvm-svn: 96893 | 
| | 
| 
| 
| | llvm-svn: 96892 | 
| | 
| 
| 
| 
| 
| 
| | __alignof__ operator, make sure to take into account the packed alignment
of the struct/union/class itself. Matches GCC's behavior and fixes PR6362.
llvm-svn: 96884 | 
| | 
| 
| 
| | llvm-svn: 96883 | 
| | 
| 
| 
| 
| 
| | question is a primary virtual base of some other base.
llvm-svn: 96881 | 
| | 
| 
| 
| 
| 
| | Remove a debug printf, and add the test case that now passes.
llvm-svn: 96880 | 
| | 
| 
| 
| 
| 
| | :) My test case now has the right values but in the wrong order.
llvm-svn: 96877 | 
| | 
| 
| 
| 
| 
| | my local test case, but not the right values.
llvm-svn: 96874 | 
| | 
| 
| 
| 
| 
| | and into libAnalysis.
llvm-svn: 96872 | 
| | 
| 
| 
| | llvm-svn: 96855 | 
| | 
| 
| 
| | llvm-svn: 96853 | 
| | 
| 
| 
| | llvm-svn: 96850 | 
| | 
| 
| 
| | llvm-svn: 96848 | 
| | 
| 
| 
| 
| 
| | No functionality change.
llvm-svn: 96847 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 1) emit base destructors as aliases to their unique base class destructors
under some careful conditions.  This is enabled for the same targets that can
support complete-to-base aliases, i.e. not darwin.
2) Emit non-variadic complete constructors for classes with no virtual bases
as calls to the base constructor.  This is enabled on all targets and in
theory can trigger in situations that the alias optimization can't (mostly
involving virtual bases, mostly not yet supported).
These are bundled together because I didn't think it worthwhile to split them,
not because they really need to be.
llvm-svn: 96842 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| | llvm-svn: 96819 | 
| | 
| 
| 
| 
| 
| | itself rewritten. Radar 7669784.
llvm-svn: 96798 | 
| | 
| 
| 
| 
| 
| | declaration. This is the trivial part of PR6365.
llvm-svn: 96792 | 
| | 
| 
| 
| | llvm-svn: 96788 | 
| | 
| 
| 
| 
| 
| | between cv1 T* and cv2 T*.
llvm-svn: 96787 | 
| | 
| 
| 
| 
| 
| | CLANG_VTABLE_DEBUG.
llvm-svn: 96785 |