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

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 wrote:

...

On Apr 6, 2024, at 12:57 PM, Ruben Perez 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 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

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/1d7cceff6c8a5d40593776d75...

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.