| 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
|
| |
|
|
| |
llvm-svn: 97063
|
| |
|
|
| |
llvm-svn: 97062
|
| |
|
|
| |
llvm-svn: 97061
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 97035
|
| |
|
|
| |
llvm-svn: 97032
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 97020
|
| |
|
|
|
|
| |
Windows and Mac OS X. Will investigate later.
llvm-svn: 97016
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 97009
|
| |
|
|
|
|
| |
a block pointer type. Fixes radar 7682149.
llvm-svn: 97008
|
| |
|
|
| |
llvm-svn: 97005
|
| |
|
|
| |
llvm-svn: 97002
|
| |
|
|
| |
llvm-svn: 96999
|
| |
|
|
|
|
| |
temporary name
llvm-svn: 96998
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 96978
|
| |
|
|
|
|
|
|
| |
(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: 96968
|
| |
|
|
| |
llvm-svn: 96962
|
| |
|
|
| |
llvm-svn: 96961
|
| |
|
|
| |
llvm-svn: 96958
|
| |
|
|
| |
llvm-svn: 96941
|
| |
|
|
|
|
|
| |
in the recent changes to RegionStore::InvalidateRegions(). Note that we
are still not yet modeling 'memcpy()' explicitly.
llvm-svn: 96902
|
| |
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 96875
|
| |
|
|
|
|
| |
my local test case, but not the right values.
llvm-svn: 96874
|
| |
|
|
|
|
| |
and into libAnalysis.
llvm-svn: 96872
|