[PATCH] D90719: [DebugInfo] Modify ctor homing as workaround for unconstructed libcxx types

[Amy Huang via Phabricator via cfe-commits]

akhuang added a comment.

In D90719#2377485 <https://reviews.llvm.org/D90719#2377485>, @dblaikie wrote:

> In D90719#2377324 <https://reviews.llvm.org/D90719#2377324>, @rnk wrote:
>
>> I had another thought, which is that even if it is UB, perhaps we really shouldn't be using UB as the basis for debug info emission. All programs have bugs, and most bugs invoke some form of UB. If we don't provide sufficient info when UB is involved, it can become harder to find the UB. The vtable type homing heuristic works because violating the heuristic assumptions typically results in a link error. Creating an object without calling the class's constructor is the kind of UB that is likely to manifest as runtime errors.
>>
>> Which is to say, I'm in favor of Amy's change as written.
>
> The same would be true for the ctor homing generally though, I think? If there was a user-defined ctor and someone chose not to call it, that'd be UB too. I'm not sure there's especially more cases of not calling implicit non-trivial ctors versus non-trivial explicit non-trivial ctors to diverge on this criteria?

That's true. I was kind of thinking of this as a workaround for this particular libcxx issue, and if it becomes no longer an issue in libcxx, we could revert it.

Anyway, guess it would be good to know why libcxx does things this way and whether it could be changed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90719