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

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D90719#2387379 <https://reviews.llvm.org/D90719#2387379>, @akhuang wrote:

> + @ldionne for libc++ input?
>
> To summarize, this constructor homing debug info optimization makes the assumption that if a class is being used then its constructor must have been called at some point. We noticed that some libc++ types (such as __hash_node) are nontrivial but the constructor is never called (instead there's some allocation and then the members are constructed separately).
>
> Basically we're not sure if this can be fixed from the libc++ side but it would be nice to have some more input about this. For example would it be possible to call the constructor when __hash_node is created?
>
>> My guess would be that this doesn't come up often enough to merit an attribute, etc, and that libc++ is fixable. (if the code really wants to do no work when constructing, changing the type to have a trivial ctor and the places that want non-trivial construction can initialize the members as needed seems like it'd be viable)
>
> I looked at the code again and `__hash_node` also has nontrivial members, so maybe it's not as feasible to make it a nontrivial constructor.

At least my thinking is: If this type is being constructed without executing a constructor and the code is correct (modulo UB, but correct for the behavior it happens to be getting) then it doesn't really need those ctors to run - so perhpas they shouldn't be there either/should be trivial, because they're not being used, at least here. That's my theory, at least.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90719