to be careful to emit landing pads that are always prepared to handle a
cleanup path. This is correct mostly because of the fix to the LLVM
inliner, r132200.
llvm-svn: 132209
within class templates when they are necessary to complete the type of
the member. The canonical example is code like:
template <typename T> struct S {
static const int arr[];
static const int x;
static int f();
};
template <typename T> const int S<T>::arr[] = { 1, 2, 3 };
template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]);
template <typename T> int S<T>::f() { return x; }
int x = S<int>::f();
We need to instantiate S<T>::arr's definition to pick up its initializer
and complete the array type. This involves new code to specially handle
completing the type of an expression where the type alone is
insufficient. It also requires *updating* the expression with the newly
completed type. Fortunately, all the other infrastructure is already in
Clang to do the instantiation, do the completion, and prune out the
unused bits of code that result from this instantiation.
This addresses the initial bug in PR10001, and will be a step to
fleshing out other cases where we need to work harder to complete an
expression's type. Who knew we still had missing C++03 "features"?
llvm-svn: 132172
issues and also add a test.
We should now handle defaulted members of templates properly. No
comment as to whether or not this also holds for templated functions,
but defaulting those is kind of insane.
llvm-svn: 131938
fixes PR9965, but we're not out of the water yet, as we do not
successfully handle out-of-line definitions, due to my utter
misunderstanding of how we manage templates.
llvm-svn: 131920
non-POD/non-trivial object throuugh a C-style varargs. The warning
itself was default-mapped to error, but can be downgraded, but we were
treating it in Sema like a hard error, silently dropping the call.
Instead, treat this problem like a warning, and do what the warning
says we do: abort at runtime. To do so, we fake up a __builtin_trap()
expression that gets evaluated as part of the argument.
llvm-svn: 131805
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
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
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
if they match that production, i.e. if they're template type parameters
or decltypes (or, as an obvious case not yet described in the ABI document,
if they're template template parameters applied to template arguments).
llvm-svn: 130824
the body of a delegating constructor call.
This means that the delegating constructor implementation should be
complete and correct, though there are some rough edges (diagnostic
quality with the cycle detection and using a deleted destructor).
llvm-svn: 130803
This test seeks a verbose comment in output. By default, "-integrated-as" sets verbose-asm. Cygming is not ready for -integrated-as yet.
llvm-svn: 130681
parameter node and use this to correctly mangle parameter
references in function template signatures.
A follow-up patch will improve the storage usage of these
fields; here I've just done the lazy thing.
llvm-svn: 130669
As far as I know, this implementation is complete but might be missing a
few optimizations. Exceptions and virtual bases are handled correctly.
Because I'm an optimist, the web page has appropriately been updated. If
I'm wrong, feel free to downgrade its support categories.
llvm-svn: 130642
-C++ objects with user-declared constructor don't need zero'ing.
-We can zero-initialize arrays of C++ objects in "bulk" now, in which case don't zero-initialize each object again.
llvm-svn: 130453
make sure to mark the destructor. This normally isn't required,
because the destructor should have been marked as part of the
declaration of the local, but it's necessary when the variable
is a parameter because it's the call sites that are responsible
for those destructors.
llvm-svn: 130372
Patch authored by John Wiegley.
These type traits are used for parsing code that employs certain features of
the Embarcadero C++ compiler. Several of these constructs are also desired by
libc++, according to its project pages (such as __is_standard_layout).
llvm-svn: 130342
I've sent off an email requesting clarification on a few things that
I wasn't sure how to handle.
This also necessitated making prefixes and unresolved-prefixes get
mangled separately.
llvm-svn: 130083
APInt::toString doesn't do those, but it's easy to postprocess that output,
and that's probably better than adding another knob to that method.
llvm-svn: 130081
turns out that a field or base needs to be laid out in the tail padding of
the base, CGRecordLayoutBuilder::ResizeLastBaseFieldIfNecessary will convert
it to an array of i8.
I've audited the new test results to make sure that they are still valid. I've
also verified that we pass a self-host with this change.
This (finally) fixes PR5589!
llvm-svn: 129673
weak linkage. Also, fix a problem where global weak variables
with non-trivial initializers were getting guard variables, or at
least were checking for them and then crashing.
llvm-svn: 129342
for __unknown_anytype resolution to destructively modify the AST. So that's
what it does now, which significantly simplifies some of the implementation.
Normal member calls work pretty cleanly now, and I added support for
propagating unknown-ness through &.
llvm-svn: 129331
__block object copy/dispose helpers for C++ objects with those for
different variables with completely different semantics simply because
they happen to both be no more aligned than a pointer.
Found by inspection.
Also, internalize most of the helper generation logic within CGBlocks.cpp,
and refactor it to fit my peculiar aesthetic sense.
llvm-svn: 128618
Emit them instead with the linkage of the VTT.
I'm actually really ambivalent about this; it's what GCC does, but outside
of improving code size (if the linkage is coalescing), I'm not sure it's
at all relevant. Construction vtables are naturally referenced only by the
VTT, which is itself only referenced by complete-object constructors and
destructors; giving the construction vtables possibly-external linkage is
important if you have an optimization that drills through the VTT to a
reference to a particular construction vtable which it cannot just emit
itself.
llvm-svn: 128374
they don't collide with file-scope extern functions from the same
translation unit. This is basically a matter of applying the same
logic to FunctionDecls as we were previously applying to VarDecls.
llvm-svn: 128072
Issue this as an IR-gen error; it's not really worthwhile doing this
"right", i.e. in Sema, because IR gen knows a lot of tricks beyond
what the constant evaluator knows.
llvm-svn: 127854
allocation and therefore requires a null-check. We were doing that, but
we weren't treating the new-initializer as being conditionally executed,
which means it was possible to get ill-formed IR as in PR9298.
llvm-svn: 127147
computing for a nested decl with explicit visibility. This is all part
of the general philosophy of explicit visibility attributes, where
any information that was obviously available at the attribute site
should probably be ignored. Fixes PR9371.
llvm-svn: 126992
necessarily enclose the innermost normal cleanup depth, because
the top of the jump scope stack might be an EH cleanup or EH scope.
Fixes PR9303.
llvm-svn: 126472
without defining them. This should be an error, but I'm paranoid about
"uses" that end up not actually requiring a definition. I'll revisit later.
Also, teach IR generation to not set internal linkage on variable
declarations, just for safety's sake. Doing so produces an invalid module
if the variable is not ultimately defined.
Also, fix several places in the test suite where we were using internal
functions without definitions.
llvm-svn: 126016
class and to bind the shared value using OpaqueValueExpr. This fixes an
unnoticed problem with deserialization of these expressions where the
deserialized form would lose the vital pointer-equality trait; or rather,
it fixes it because this patch also does the right thing for deserializing
OVEs.
Change OVEs to not be a "temporary object" in the sense that copy elision is
permitted.
This new representation is not totally unawkward to work with, but I think
that's really part and parcel with the semantics we're modelling here. In
particular, it's much easier to fix things like the copy elision bug and to
make the CFG look right.
I've tried to update the analyzer to deal with this in at least some
obvious cases, and I think we get a much better CFG out, but the printing
of OpaqueValueExprs probably needs some work.
llvm-svn: 125744
Douglas Gregor