| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
was being treated as postfix '--' in C mode.
llvm-svn: 131770
|
| |
|
|
|
|
|
| |
This case is tested by the fact that the modified test produces
significatly worse diagnostics. That's on the list.
llvm-svn: 131759
|
| |
|
|
| |
llvm-svn: 131754
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Type::isUnsignedIntegerOrEnumerationType(), which are like
Type::isSignedIntegerType() and Type::isUnsignedIntegerType() but also
consider the underlying type of a C++0x scoped enumeration type.
Audited all callers to the existing functions, switching those that
need to also handle scoped enumeration types (e.g., those that deal
with constant values) over to the new functions. Fixes PR9923 /
<rdar://problem/9447851>.
llvm-svn: 131735
|
| |
|
|
|
|
|
| |
to a warning, since apparently libstdc++'s debug mode does this (and
we can recover safely). Add a Fix-It to insert the "inline", just for kicks.
llvm-svn: 131732
|
| |
|
|
|
|
|
| |
manifested in a crash with blocks in PR9953, but it was a ticking time
bomb for normal functions, too. Fixes PR9953.
llvm-svn: 131731
|
| |
|
|
|
|
| |
useful
llvm-svn: 131728
|
| |
|
|
| |
llvm-svn: 131722
|
| |
|
|
|
|
| |
constructor" again
llvm-svn: 131706
|
| |
|
|
|
|
| |
reason about.
llvm-svn: 131702
|
| |
|
|
| |
llvm-svn: 131701
|
| |
|
|
|
|
| |
template case.
llvm-svn: 131692
|
| |
|
|
| |
llvm-svn: 131691
|
| |
|
|
| |
llvm-svn: 131672
|
| |
|
|
| |
llvm-svn: 131670
|
| |
|
|
| |
llvm-svn: 131640
|
| |
|
|
|
|
| |
for destructors until the class is complete and destructors have been adjusted.
llvm-svn: 131632
|
| |
|
|
|
|
| |
implementations.
llvm-svn: 131614
|
| |
|
|
| |
llvm-svn: 131611
|
| |
|
|
|
|
| |
other things, libcxx not building.
llvm-svn: 131573
|
| |
|
|
| |
llvm-svn: 131528
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
member functions by making sure that they're on the record before
checking for deletion.
Also make sure source locations are valid to avoid crashes.
Unfortunately, the declare-all-implicit-members approach is still
required in order to ensure that dependency loops do not result in
incorrectly deleting functions (since they are to be deleted at the
declaration point per the standard).
Fixes PR9917
llvm-svn: 131520
|
| |
|
|
|
|
|
| |
user specified string class via -fconstant-string-class option.
pr9914.
llvm-svn: 131496
|
| |
|
|
|
|
| |
creating aggregate stores in common cases. This is more friendly to fast-isel.
llvm-svn: 131490
|
| |
|
|
|
|
|
| |
optimization for abstract classes; there was a misunderstanding, and
it turns out that there are no kexts which rely on this.
llvm-svn: 131489
|
| |
|
|
|
|
|
| |
constructors, including two more FIXMEs (one of which I don't actually
understand).
llvm-svn: 131487
|
| |
|
|
|
|
|
|
| |
I have on that's #if 0'ed out, and I don't know why it's failing to
delete the constructor. I'd appreciate if someone familiar with access
control could look into ShouldDeleteDefaultConstructor - thanks.
llvm-svn: 131486
|
| |
|
|
|
|
| |
darwin assembler can handle cfi. Add a test.
llvm-svn: 131464
|
| |
|
|
| |
llvm-svn: 131446
|
| |
|
|
|
|
| |
suppress an error we were previously emitting on valid union code.
llvm-svn: 131440
|
| |
|
|
| |
llvm-svn: 131435
|
| |
|
|
|
|
| |
reasons that honestly really, really need to be looked into.
llvm-svn: 131434
|
| |
|
|
|
|
| |
my defaulted constructor tests stop yelling at me about them.
llvm-svn: 131432
|
| |
|
|
| |
llvm-svn: 131403
|
| |
|
|
|
|
| |
131365 caused PR9927.
llvm-svn: 131401
|
| |
|
|
|
|
|
| |
optimization. Make sure to require a vtable when trying to get the address
of a VTT, otherwise we would never end up emitting the VTT.
llvm-svn: 131400
|
| |
|
|
| |
llvm-svn: 131396
|
| |
|
|
|
|
|
|
|
| |
operators; their semantics are guaranteed by the language.
If someone wants to argue that freestanding compiles shouldn't recognize
this, I might be convinceable.
llvm-svn: 131395
|
| |
|
|
| |
llvm-svn: 131385
|
| |
|
|
|
|
|
|
|
| |
nested-name-specifier, re-evaluate the nested-name-specifier as if we
were entering that context (which we did!), so that we'll resolve a
template-id to a particular class template partial
specialization. Fixes PR9913.
llvm-svn: 131383
|
| |
|
|
|
|
|
| |
It can be larger, it can be smaller, it can be signed, whatever. Handle
all the crazy cases with grace and spirit.
llvm-svn: 131378
|
| |
|
|
| |
llvm-svn: 131372
|
| |
|
|
|
|
| |
Also follow gcc in that arrays of elements with zero size are encoded as arrays with zero elements.
llvm-svn: 131369
|
| |
|
|
|
|
|
|
|
|
| |
that the destructor body is trivial and that all member variables also have either
trivial destructors or trivial destructor bodies, we don't need to initialize the
vtable pointers since no virtual member functions will be called on the destructor.
Fixes PR9181.
llvm-svn: 131368
|
| |
|
|
|
|
|
|
|
| |
send if the receiver is null. Normally it's not worthwhile to check this,
but avoiding the null-initialization is nice, and this also avoids nasty
problems where the null-initialization is visible within the call because
we use an aliased result buffer. rdar://problem/9402992
llvm-svn: 131366
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Go through and expand the members of bases into the encoding string (and encode the VTable as well).
Unlike gcc which expands virtual bases as many times as they appear in the
hierarchy, clang will only expand them once at the end, to reflect the actual layout.
Note that there doesn't seem to be a way to indicate in the encoding that
packing/alignment of members is different that normal, in which case
the encoding will be out-of-sync with the real layout.
If the runtime switches to just consider the size of types without
taking into account alignment, we could easily make padding explicit in the
encoding (e.g. using arrays of chars). The encoding strings would be
longer then though.
Also encode a flexible array member as array of 0 size, like gcc, not as a pointer.
llvm-svn: 131365
|
| |
|
|
|
|
|
|
| |
There are APIs, e.g. [NSValue valueWithBytes:objCType:], which use the encoding to find out
the size of an object pointed to by a pointer. Make things safer by making it illegal to @encode
incomplete types.
llvm-svn: 131364
|
| |
|
|
|
|
|
|
|
|
|
|
| |
template<class U>
struct X1 {
template<class T> void f(T*);
template<> void f(int*) { }
};
Won't be so simple. I need to think more about it.
llvm-svn: 131362
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
scope.
Necessary to parse MFC and MSVC standard lib code.
Example:
struct X {
template<class T> void f(T) { }
template<> void f(int) { }
}
llvm-svn: 131347
|
| |
|
|
|
|
|
|
| |
the right order.
Also, don't reject alias templates in all ElaboratedTypes: some ElaboratedTypes do not correspond to elaborated-type-specifiers.
llvm-svn: 131342
|