Re: [release] Boost 1.85.0 Release Candidate 1 is available

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-04-07 22:31:28

On 4/8/24 00:11, Andrey Semashev wrote:
> On 4/7/24 20:39, Marshall Clow via Boost wrote:
>>> On Apr 6, 2024, at 10:35 PM, Marshall Clow <mclow.lists_at_[hidden]> wrote:
>>>
>>>> On Apr 6, 2024, at 12:57 PM, Ruben Perez <rubenperez038_at_[hidden]> wrote:
>>>>
>>>>> As always, the release managers would appreciate it if you download the
>>>>> candidate of your choice and give building it a try. Please report both
>>>>> success and failure, and anything else that is noteworthy.
>>>>
>>>> Program options seem to fail to build under C++23 (Ubuntu 22.04,
>>>> clang-19, release). Here's the build log:
>>>
>>> Ruben —
>>>
>>> Did the 1.85.0 beta have this same problem?
>>
>> I suspect that the problem was introduced in this commit:
>>
>> commit 847b130e19a9e5118bfb5486e9b4d4f6ab2797a2
>> Author: Ed Catmur <ed_at_[hidden]>
>> Date:   Thu Feb 23 11:39:17 2023 +0000
>>
>>     Use BOOST_DEFAULTED_FUNCTION on empty destructors (#122)
>>     
>>     The compiler-generated copy constructor and copy assignment operator are deprecated since C++11 on classes with user-declared destructors.
>>     
>>     This change allows clean compilation with the -Wdeprecated-copy-dtor/-Wdeprecated-copy-with-user-provided-dtor flag.
>>     
>>     Co-authored-by: Ed Catmur <edward.catmur_at_[hidden]>
> 
> No, the problem existed before that. The problem is in the `throw()`
> specifications, which existed before the commit you referenced.
> 
> I think, it was at least partly introduced by
> fd7b310993133fd280f4967bc3a30da7ab3dddee. In fact, at that point it was
> not a problem because at that time C++20 did not exist yet and `throw()`
> specifications were fine.

Here's my understanding of the chronology the problem:

1. In 2012, fd7b310993133fd280f4967bc3a30da7ab3dddee adds a number of
exception classes in Boost.ProgramOptions. These exception classes have
`throw()` exception specifications on their destructors and other member
functions.
2. C++20 is released. It removes `throw()` specifications from the
standard. Compilers keep accepting `throw()` in C++20 and later modes,
which is why we didn't notice.
3. In 2023, 847b130e19a9e5118bfb5486e9b4d4f6ab2797a2 changes the
destructors to `= default` in C++11 and up. This may be a contributing
factor to the clang breakage, but not the culprit.
4. In clang-19 (which is currently in development), something broke in
this support for `throw()` in C++23 mode.
5. This was reported first in
https://lists.boost.org/Archives/boost/2024/03/256179.php and then in
https://lists.boost.org/Archives/boost/2024/04/256445.php. Note the
first reported mentions that the problem is fixed if `throw()`
specifications are changed to `BOOST_NOEXCEPT`.
6. I create https://github.com/boostorg/program_options/pull/133 with
the fix proposed by Peter Dimov in
https://lists.boost.org/Archives/boost/2024/03/256180.php.
7. Peter merges the PR to develop.

So, the root problem is that we were using `throw()` unconditionally
because the code was not updated for C++20. The fact that clang-19 emits
an error only in C++23 mode, and an error that is misleading (because
exception specification must be interpreted after the enclosing class
definition is complete), is probably a bug in clang, but given that we
shouldn't be using `throw()` in the first place, that point is moot.
I'll note again that clang-19 is not released yet.

I hope, this clarifies things.

>> And it looks like it has been fixed in develop:
>>
>> 	https://github.com/boostorg/program_options/commit/1d7cceff6c8a5d40593776d7578a984852df5b75
>>
>> Is that correct?
> 
> Yes, this commit should fix the problem. I will leave it to Peter to ask
> for the permission to merge it, if he considers it important enough.
>