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
I hear at least one person crying out in anguish, but it's unfortunately
necessary to avoid infinite loops with mutually dependent constructors
trying to call each other and determine if they are deleted.
It might be possible to go back to the old behavior if we can implement
part-of-file lookups efficiently, or if a solution is discovered by
which we can safely detect and avoid infinite recusion.
llvm-svn: 131515
1. We would assume that the length of the string literal token was at least 2
2. We would allocate a buffer with size length-2
And when the stars aligned (one of which would be an invalid source location due to stale PCH)
The length would be 0 and we would try to allocate a 4GB buffer.
Add checks for this corner case and a bunch of asserts.
(We really really should have had an assert for 1.).
Note that there's no test case since I couldn't get one (it was major PITA to reproduce),
maybe later.
llvm-svn: 131492
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
Preserve the original triple in the NetBSD toolchain when using -m32 or
-m64 and the resulting effective target is different from the triple it
started with. This allows -m32 to use the same assembler/linking in
cross-compiling mode and avoids confusion about passing down target
specific flags in that case like --32.
llvm-svn: 131404
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
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
placement allocation or deallocation functions. These functions cannot be
replaced by the user and are exempt from the normal requirements on
allocation functions (e.g. that they must return unaliased memory).
llvm-svn: 131386
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
Sebastian Redl