Upgrade to C++20

[messmerd]

This was a lot easier than I was expecting.

Our Linux and Windows MinGW builds are using GCC/MinGW 9.3 which will be the limiting factor here in terms of what we can do with C++20. They barely have any C++20 support, but even the small amount they do provide should be useful.

Some highlights of what we should have now:

• Designated initializers
• Class types in non-type template parameters (though Apple Clang may only partially support this)
• char8_t and std::u8string
• bit operations and power-of-two operations (albeit with the old names)
• contains() member function of associative containers

Things we won't have yet:

• concepts
• ranges
• <=>
• coroutines
• modules
• std::span
• std::format

But once we upgrade to GCC 10, we will have some of these big C++20 features.

[JohannesLorenz]

There are still a few open comments about C++20:

$ git grep '++20'
include/ArrayVector.h:          // TODO C++20: Use std::construct_at
include/ArrayVector.h:  // TODO C++20: Replace with operator<=>
include/ArrayVector.h:  // TODO C++20: Remove
include/Flags.h:        friend constexpr auto operator==(Flags l, Flags r) -> bool { return l.m_value == r.m_value; } // TODO C++20: = default
include/Flags.h:        friend constexpr auto operator!=(Flags l, Flags r) -> bool { return l.m_value != r.m_value; } // TODO C++20: Remove
include/LmmsSemaphore.h:   @note Likely outdated with C++20's std::counting_semaphore
include/lmms_math.h:// @note Once we upgrade to C++20, we could probably use std::formatted_size

Can some of them be solved, or are the compilers limiting us here?

[messmerd]

Yes, we'd need to upgrade our GCC 9.3 (and MinGW 9.3) compilers to at least GCC 10 to begin addressing some of those.

include/ArrayVector.h: // TODO C++20: Use std::construct_at
include/ArrayVector.h: // TODO C++20: Replace with operator<=>
include/ArrayVector.h: // TODO C++20: Remove
include/Flags.h: friend constexpr auto operator==(Flags l, Flags r) -> bool { return l.m_value == r.m_value; } // TODO C++20: = default
include/Flags.h: friend constexpr auto operator!=(Flags l, Flags r) -> bool { return l.m_value != r.m_value; } // TODO C++20: Remove

These will be possible with GCC 10.

include/LmmsSemaphore.h: @note Likely outdated with C++20's std::counting_semaphore

This will be possible with GCC 11.

include/lmms_math.h:// @note Once we upgrade to C++20, we could probably use std::formatted_size

This will be possible with GCC 13.

[JohannesLorenz]

In src/gui/editors, I get this warning with g++ 14.2.1 on Linux:

bitwise operation between different enumeration types 'Qt::Modifier' and 'Qt::Key' is deprecated [-Wdeprecated-enum-enum-conversion]

Files:

AutomationEditor.cpp:2040:45
AutomationEditor.cpp:2044:46
AutomationEditor.cpp:2047:48
AutomationEditor.cpp:2050:48
Editor.cpp:121:46
Editor.cpp:122:46
PianoRoll.cpp:4767:44
PianoRoll.cpp:4768:45
PianoRoll.cpp:4769:46
PianoRoll.cpp:4770:49
PianoRoll.cpp:4829:42
PianoRoll.cpp:4830:43
PianoRoll.cpp:4831:44
PianoRoll.cpp:4852:44
PianoRoll.cpp:4856:45
PianoRoll.cpp:4860:43
PianoRoll.cpp:4864:50

So, this PR adds new warnings on Linux, which might be unwanted, or strategy if you plan to keep them as TODO markers.

[JohannesLorenz]

There might be clang-tidy checks that could be applied now. However, it might be a fair design decision to keep this PR minimal (i.e. without these modernizations), especially since clang-tidy is known to sometimes produce buggy results.

From the clang-tidy list , I see at least:

• modernize-use-designated-initializers
• readability-container-contains

[JohannesLorenz]

My review is positive, with 1 optional code comment, 2 optional conversation comments (see above).

What I checked:

• Functional review ✔️
• Style review ✔️
• Test review ✔️

[messmerd]

In src/gui/editors, I get this warning with g++ 14.2.1 on Linux

Should be fixed now

EDIT: I messed it up - the QKeySequence constructor didn't work the way I expected it to, so I added a helper function to combine keys and modifiers without any deprecation warnings

[JohannesLorenz]

93ed53a (which you just pushed) compiles without warnings for me

[JohannesLorenz]

This has 2 reviews of developers, and all kinds of reviews are covered. No one else complained in the last 2 weeks. Is there any reason to prevent merging?

[JohannesLorenz]

After the rework, I now tested the key sequences - still working.