dblaikie added a comment. In D90719#2372554 <https://reviews.llvm.org/D90719#2372554>, @rnk wrote:
> In D90719#2372463 <https://reviews.llvm.org/D90719#2372463>, @dblaikie wrote: > >> Does Chromium need this fixed in clang? Or if it were fixed in libc++ would >> that be adequate? (does Chromium's build need to work with old libc++s, or >> does it always build with a libc++ that matches the compiler? (in the latter >> case, a fix in libc++ would be as good as a fix in clang)) > > Well, we'd like to make this new type homing behavior the default, and it > wouldn't work with old libc++ versions, and there is the general possibility > that there is code out there like this libc++ code that has implicit > nontrivial constructors that are not used. So, I wouldn't think so much about > what's right for Chrome, and more about what's right for Clang. My understanding is that such code is UB, is that right? - if libc++ was threading some needle/depending on some agreed upon Clang guarantee (even if it was a secret handshake only for libc++) then I'd be more in favor of the "we have to/should support it" but as it seems to stand, I'm inclined towards addressing this by fixing libc++ unless there's evidence of a pervasive dependence on this UB. > If we do want to fix libc++, I'd warn you that the code is subtle. It takes > care to construct the node value in a particular way, and it sets a flag > after construction succeeds, which perhaps affects exception safety: > https://github.com/llvm/llvm-project/blob/master/libcxx/include/__hash_table#L2456 > + @EricWF Yeah, +1 on getting @EricWF's take on this for sure. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90719/new/ https://reviews.llvm.org/D90719 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
