Fixes https://github.com/llvm/llvm-project/issues/52906
Unless I'm mistaken, this
- preserves the size and layout of lognormal_distribution<T>; but
- shrinks the size of lognormal_distribution<T>::param_type (this is the ABI break).
Differential D116344
[libc++] [ABI BREAK] Conform lognormal_distribution::param_type. • Quuxplusone on Dec 28 2021, 3:07 PM. Authored by
Details
Fixes https://github.com/llvm/llvm-project/issues/52906 Unless I'm mistaken, this
Diff Detail
Event TimelineComment Actions SGTM, but I'm not too familiar with this part of the library.
Comment Actions These changes are hard. We don't have any way to tell whether it's going to bite someone, and chances are that it won't hurt anyone. But if it does, it's exactly the kind of thing that's going to be a huge pain to debug, and it's also going to be unfixable from their end once they find out what the issue is. For these reasons, and because the behavior we're fixing is bad but also not like fixing basic functionality, I think it would be better to hide this behind an ABI macro.
Comment Actions What I mean here is that their code probably worked previously, and they had never noticed this bug. It's not like if lognormal_distribution had never worked properly and we were suddenly making it work -- I think an ABI break would be legit, cause nobody could really have been using it in the first place. Now this is sneakier. Comment Actions Add a release note; add a macro to revert to the old behavior. The wording is copied from the release note above the new one, because I think "remove the bad UB code in LLVM 15" sounds like a great plan.
Comment Actions Okay, so the strategy here is:
I'm fine with this approach since I don't think anybody's going to be impacted -- IOW this is a small risk for an interesting benefit. FWIW, "these people" are most likely vendors who will discover any potential breakage through their users complaining over the next year or so, if that happens at all. If it does, we will make this a proper ABI macro and only enable it in the ABI-unstable build. Pinging libc++ vendors to see if they have an opinion. @Quuxplusone please feel free to ship this at the end of this week if nobody has raised any concerns. Comment Actions I agree with everything you said except this sentence. I don't believe we know a realistic path to ever make "ABIv2" the default, which means that if we do this patch only in ABIv2, then we're not doing it by default for "new customers" (so to speak). And I think this UB is a big enough deal that it needs to be fixed-by-default for new customers. If anyone complains about the new lognormal_distribution (which I think we both believe is highly unlikely), then I think we would have to investigate some way to keep this patch enabled by default for ABIv1 users, but disabled for those specific vendors who complained — which I think means simply "do exactly this PR, but commit to supporting the _LIBCPP_ABI_OLD_LOGNORMAL_DISTRIBUTION macro forever." Comment Actions I knew you (or someone else) was going to suggest that, which is why I worded my comment above to unambiguously suggest that the default was going to be "no ABI break". I think there's definitely logic in what you suggest, however the default so far has always be that non-benign [1] ABI breaking changes were opted-into, not opted-out. We could discuss changing that policy, but it's a much much larger discussion. It would indeed make some sense that the library be "unstable" by default, but that we provide mechanisms for vendors to keep their flavour of the library ABI stable. But that's an entirely new dynamic for the project and we would need vendors to be organized and to pay attention to what's shipped on their systems a lot more than they need to be today. [1]: By a non-benign change, I mean a change that affects some people. For example, if we break the ABI in such a tiny way that nobody ever notices cause nobody was ever depending on that ABI, it's a benign change and I'm supportive of not even having a macro for it. That would just make our lives harder without benefit. Comment Actions
I'll try to remember to land this on Monday. |
If I'm correct we go from 3 * sizeof(result_type) + sizeof(bool) to 2 * sizeof(result_type). So it would be possible use an ABI macro. Right?