[PATCH] D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

In D61165#1492724 <https://reviews.llvm.org/D61165#1492724>, @rjmccall wrote:

> In D61165#1492582 <https://reviews.llvm.org/D61165#1492582>, @erik.pilkington wrote:
>
> > Duncan pointed out eel.is/c++draft/class.init#class.base.init-13, which appears to claim that initialization ends with the execution of the constructor, excluding temporary destructors.
> >
> > > (13) In a non-delegating constructor, initialization proceeds in the following order:
> > >  /* list of steps... */
> > >  (13.4) **Finally, the compound-statement of the constructor body is executed.**
> >
> > John: do you agree with this analysis?
>
>
> That's talking about constructor bodies.


Sure, but that's all that dcl.int suggests happens during initialization.  Skipping over paragraphs that don't apply:

> http://eel.is/c++draft/dcl.init#17: The semantics of initializers are as follows.
> 
> - http://eel.is/c++draft/dcl.init#17.6: [I]f the destination type is a (possibly cv-qualified) class type:
>   - http://eel.is/c++draft/dcl.init#17.6.2: [I]f the initialization is direct-initialization, or if it is copy-initialization where the cv-unqualified version of the source type is the same class as, or a derived class of, the class of the destination, constructors are considered. The applicable constructors are enumerated ([over.match.ctor]), and the best one is chosen through overload resolution ([over.match]). **Then:**
>     - http://eel.is/c++draft/dcl.init#17.6.2.1: If overload resolution is successful, **the selected constructor is called to initialize the object**, with the initializer expression or expression-list as its argument(s).

Which I read as saying, "the selected constructor is the thing that initializes the object".  But, IIUC, you're saying the object isn't necessarily initialized when the selected constructor returns.  I can't find any text that would support your interpretation.

Let me argue from the other direction as well:

> http://eel.is/c++draft/dcl.init#21: An object whose initialization has completed is deemed to be constructed, [...]

IIUC, you're suggesting that there could be a "constructed, but not yet initialized" state, but the definition of "constructed" seems to refute that.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61165/new/

https://reviews.llvm.org/D61165