Commit Graph

4 Commits

Author SHA1 Message Date
Richard Smith 3501895863 Revert r345562: "PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of type"
This exposes a (known) CodeGen bug: it can't cope with emitting lvalue
expressions that denote non-odr-used but usable-in-constant-expression
variables. See PR39528 for a testcase.

Reverted for now until that issue can be fixed.

llvm-svn: 346065
2018-11-03 02:23:33 +00:00
Richard Smith d2e69dfddb PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of type
nullptr_t does not access memory.

We now reuse CK_NullToPointer to represent a conversion from a glvalue
of type nullptr_t to a prvalue of nullptr_t where necessary.

llvm-svn: 345562
2018-10-30 02:02:49 +00:00
Richard Smith b6070db0d0 DR1672, DR1813, DR1881, DR2120: Implement recent fixes to "standard
layout" rules.

The new rules say that a standard-layout struct has its first non-static
data member and all base classes at offset 0, and consider a class to
not be standard-layout if that would result in multiple subobjects of a
single type having the same address.

We track "is C++11 standard-layout class" separately from "is
standard-layout class" so that the ABIs that need this information can
still use it.

Differential Revision: https://reviews.llvm.org/D45176

llvm-svn: 329332
2018-04-05 18:55:37 +00:00
Richard Smith df054d3d22 C++ DR1611, 1658, 2180: implement "potentially constructed subobject" rules for special member functions.
Essentially, as a base class constructor does not construct virtual bases, such
a constructor for an abstract class does not need the corresponding base class
construction to be valid, and likewise for destructors.

This creates an awkward situation: clang will sometimes generate references to
the complete object and deleting destructors for an abstract class (it puts
them in the construction vtable for a derived class). But we can't generate a
"correct" version of these because we can't generate references to base class
constructors any more (if they're template specializations, say, we might not
have instantiated them and can't assume any other TU will emit a copy).
Fortunately, we don't need to, since no correct program can ever invoke them,
so instead emit symbols that just trap.

We should stop emitting references to these symbols, but still need to emit
definitions for compatibility.

llvm-svn: 296275
2017-02-25 23:53:05 +00:00