| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
VarDecl.
llvm-svn: 207867
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, we would generate a single name for all reference
temporaries and allow LLVM to rename them for us. Instead, number the
reference temporaries as we build them in Sema.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3554
llvm-svn: 207776
|
| |
|
|
|
|
|
|
| |
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D3551
llvm-svn: 207734
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since the community says that a blacklist is not good enough, and I don't have
enough time now to implement a proper whitelist, let's just remove the
attribute validation.
But, nevertheless, we can still communicate in the generated XML if our parser
found an issue with the HTML. But this bit is best-effort and is specifically
called out in the schema as such.
llvm-svn: 207712
|
| |
|
|
|
|
|
|
|
| |
if-conditions.
I think this is the last commit for ARM64 big endian in clang. This commit makes
arm_neon.h compile correctly.
llvm-svn: 207624
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It is possible that a variable template specialization might not have a
VisibilityAttr attached to it while the template that it specializes
does, in fact, have one.
We should consider the template in such cases.
This fixes PR19597.
llvm-svn: 207498
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A reference temporary should inherit the linkage of the variable it
initializes. Otherwise, we may hit cases where a reference temporary
wouldn't have the same value in all translation units.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3515
llvm-svn: 207451
|
| |
|
|
|
|
|
|
|
|
| |
parameters from the original FullComment,
if the parameters are not already set (e.g. because it is a typedef).
Fixes crash of rdar://16128173
llvm-svn: 207382
|
| |
|
|
|
|
|
|
|
|
| |
are no
designated initializers in the super class hierarchy then it should return false.
rdar://16692535
llvm-svn: 207332
|
| |
|
|
|
|
| |
still in review.
llvm-svn: 207296
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We never aka vector types because our attributed syntax for it is less
comprehensible than the typedefs. This leaves the user in the dark when
the typedef isn't named that well.
Example:
v2s v; v4f w;
w = v;
The naming in this cases isn't even that bad, but the error we give is
useless without looking up the actual typedefs.
t.c:6:5: error: assigning to 'v4f' from incompatible type 'v2s'
Now:
t.c:6:5: error: assigning to 'v4f' (vector of 4 'float' values) from
incompatible type 'v2s' (vector of 2 'int' values)
We do this for all diagnostics that print a vector type.
llvm-svn: 207267
|
| |
|
|
| |
llvm-svn: 207138
|
| |
|
|
| |
llvm-svn: 207039
|
| |
|
|
| |
llvm-svn: 207007
|
| |
|
|
|
|
|
|
| |
Mangle ref-qualifiers like the Nov 2013 CTP.
This fixes PR19361.
llvm-svn: 206946
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 206945
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 206944
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 206943
|
| |
|
|
|
|
|
|
| |
overrider is present in both a vbase and nvbase
Reviewed at http://reviews.llvm.org/D3449
llvm-svn: 206908
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3272
llvm-svn: 206891
|
| |
|
|
|
|
|
|
|
|
|
| |
through to the output even if the input comment comes from an untrusted source
Attribute filtering is currently based on a blacklist, which right now includes
all event handler attributes (they contain JavaScipt code). It should be
switched to a whitelist, but going over all of the HTML5 spec requires a
significant amount of time.
llvm-svn: 206882
|
| |
|
|
|
|
|
| |
This was probably a benign bug, since nobody would look at the vbtable
slots that we were filling in.
llvm-svn: 206508
|
| |
|
|
|
|
|
|
| |
inheritance cases
Reviewed at http://reviews.llvm.org/D3410
llvm-svn: 206504
|
| |
|
|
|
|
|
|
| |
Also fix a few other vtordisp-related bugs.
Reviewed at http://reviews.llvm.org/D3400
llvm-svn: 206457
|
| |
|
|
| |
llvm-svn: 206411
|
| |
|
|
|
|
|
|
|
|
| |
the class
introduces new initializers.
Part of rdar://16568441
llvm-svn: 206409
|
| |
|
|
|
|
|
|
| |
implicit casts in C++.
Fixes <rdar://problem/16631033>.
llvm-svn: 206360
|
| |
|
|
|
|
|
|
|
| |
When instantiating an array that has an alignment attribute on it, we
were looking through the array type and only considering the element
type for the resulting alignment. We need to make sure we take the
array's requirements into account too.
llvm-svn: 206317
|
| |
|
|
|
|
| |
The Ts/Tu/Te manglings should occur before the nested-name's N.
llvm-svn: 206247
|
| |
|
|
|
|
| |
DeclContext is (lexically) within a C language linkage specification.
llvm-svn: 206204
|
| |
|
|
|
|
|
|
|
| |
Don't consider a __declspec(align) on a bitfield's declaration if it didn't
allocate any underlying storage.
This fixes PR19414.
llvm-svn: 206132
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, it was believed that #pragma vtordisp(0) would prohibit the
generation of any and all vtordisps.
In actuality, it only disables the generation of additional vtordisps.
This fixes PR19413.
llvm-svn: 206124
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 206111
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 206090
|
| |
|
|
|
|
|
| |
If a vtordisp exists between two bases, then there is no need for
additional alias avoidance padding. Test case included.
llvm-svn: 206087
|
| |
|
|
|
|
|
|
|
|
| |
A portion of the vtordisp computation that was previously unguarded by a
test for the declaration of user defined constructors/destructors was
erroniously adding vtordisps to things that shouldn't have them. This
patch correctly guards that codepath. In addition, it updates the
comments to make them more clear. Test case is included.
llvm-svn: 206077
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 206038
|
| |
|
|
|
|
|
|
| |
This patch updates the comments in RecordLayoutBuilder about record
layout in the MS-ABI. Also, I added a section about known
incompatibilities.
llvm-svn: 206010
|
| |
|
|
|
|
|
|
|
|
| |
In version 9 (VS2010) (and prior)? versions of msvc, if the last field
in a record was a bitfield padding equal to the size of the storage
class of that bitfield was added before each vbase and vtordisp. This
patch removes that feature from clang and updates the lit tests to
reflect it.
llvm-svn: 206004
|
| |
|
|
|
|
|
|
| |
The vbptr is injected after the last non-virtual base lexographically
rather than the last non-virtual base in layout order. Test case
included. Also, some line ending fixes.
llvm-svn: 206000
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When __declspec(align()) is applied to a bitfield it affects the
alignment rather than the required alignment of the struct. The major
feature that this patch adds is that the alignment of the structure
obeys the alignment of __declspec(align()) from the bitfield over the
value specified in pragma pack.
Test cases are included.
The patch also includes some small cleanups in recordlayoutbuilder and
some cleanups to some lit tests, including line endings (but no
functionality change to lit tests)
llvm-svn: 205994
|
| |
|
|
| |
llvm-svn: 205945
|
| |
|
|
|
|
|
|
|
| |
cxx-abi-dev came up with a way to disambiguate between different
keywords used in elaborated type specifiers.
This resolves certain collisions during mangling.
llvm-svn: 205943
|
| |
|
|
|
|
|
|
|
|
| |
This patch changes how we determine if padding is needed between two
bases in msvc compatibility mode. Test cases included.
In addition, a very minor change to the printing of structures to ease
lit testing.
llvm-svn: 205933
|
| |
|
|
|
|
|
|
|
|
|
| |
It is very similar to GCC's __PRETTY_FUNCTION__, except it prints the
calling convention.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D3311
llvm-svn: 205780
|
| |
|
|
|
|
| |
constant expressions.
llvm-svn: 205757
|
| |
|
|
|
|
|
|
| |
This can actually be non-zero if you override a function from a virtual
base and you have forced the most_general pointer to member
representation.
llvm-svn: 205727
|
| |
|
|
|
|
|
| |
when bridged Objective-C type conforms to the protocols in CF types's
Objective-C class. // rdar://16393330
llvm-svn: 205659
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
better. This warning will now trigger on the following conditionals:
bool b;
int i;
if (b > 1) {} // always false
if (0 <= (i > 5)) {} // always true
if (-1 > b) {} // always false
Patch by Per Viberg.
llvm-svn: 205608
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
No functionality change.
When determining the pattern for instantiating a generic lambda call operator specialization - we must not go drilling down for the 'prototype' (i.e. as written) pattern - rather we must use our partially transformed pattern (whose DeclRefExprs are wired correctly to any enclosing lambda's decls that should be mapped correctly in a local instantiation scope) that is the templated pattern of the specialization's primary template (even though the primary template might be instantiated from a 'prototype' member-template). Previously, the drilling down was haltted by marking the instantiated-from primary template as a member-specialization (incorrectly).
This prompted Richard to remark (http://llvm-reviews.chandlerc.com/D1784?id=4687#inline-10272)
"It's a bit nasty to (essentially) set this bit incorrectly. Can you put the check into getTemplateInstantiationPattern instead?"
In my reckless youth, I chose to ignore that comment. With the passage of time, I have come to learn the value of bowing to the will of the angry Gods ;)
llvm-svn: 205543
|