perf: C++20 migration + fixes

[ninetailedtori]

This PR seeks to provide a PR thread for the eventual update to C++20. This PR will act as a draft and updated periodically, to be merged when the migration occurs.

[shdwmtr]

Realistically, if we plan to move to C++ 20, there is also no reason to depend on {fmt} as its part of C++ 20 natively.

[ninetailedtori]

fmt is theoretically more efficient, but honestly, it's nice to remove having excess dependencies tbh. What would we prefer? Moving everything to std::format is very much possible :]

[shdwmtr]

fmt is theoretically more efficient

My assumption is that its likely immeasurable if there even is a difference in the first place. C++ does have some terrible standard library functions though so I wouldn't be surprised.

I don't really have a opinion then if what your saying is correct :)

[ninetailedtori]

Still uncertain, fmtlib seems faster in tests when scaled to larger batch prints compared to std::format, and another reason I didn't want to use std::format for us was it can't really handle colours, which we do use. We can migrate but swap all colours over to manual escape codes but the support for that becomes a bit more complex, especially if different shell-specs have varying escape codes that'll need us to detect shellcode at injector start possibly. Unless it's all equal, in which case we can just refactor with escape codes, though less neat I suppose xD

[ninetailedtori]

Also, I wish to keep the use of __FILE__ and __LINE__ over std::source_location due to the former being much faster in terms of lookup costs. The addition of possible zero variadic args and comma omission being supported with VA_OPT being a global c++20 extension means we can pretty simply implement them safely again (I mean, the workaround I provided in my clang PR that went through, pretty much unwrapped the entire variadic through case matching, and while it works and probably just as fast, I'll love replacing it with VA_OPT(,) VA_ARGS xD).

[ninetailedtori]

Few other things we might be able to add here. One, I've already implemented as far as we can rn, which is concepts and constraints, for API safety. Another is possible optimisation through spans or string_views, which will be a rather widespread edit, and technically string_view is possible in C++17 heheh. Still, it'll be an annoying rework, because there's 779 occurrences of std::strings, that I'll have to review, in that case. Willing to accept help on this one xD

[shdwmtr]

I like constness changes, but I'm not a huge fan of the ref and string_view changes. It would require a good sweep over and debug to ensure its still memory safe - which is useless as it already works. Ref issues when 15+ threads are constantly interoping is something I don't want to redundantly re-check.

[ninetailedtori]

I like constness changes, but I'm not a huge fan of the ref and string_view changes. It would require a good sweep over and debug to ensure its still memory safe - which is useless as it already works. Ref issues when 15+ threads are constantly interoping is something I don't want to redundantly re-check.

Hmm, string_view would be better than compared to const std::string& and const char * though. And at the least that one is safe?

[ninetailedtori]

And I am testing string_view as I go along, what I can't change I leave as string&.

[shdwmtr]

std::string_view is only as safe as the data its pointing to

[ninetailedtori]

Well, I'm going to finish cleaning up this codebase tomorrow and prolly later too, but for now this is my progress :]

[shdwmtr]

I strongly dislike one-liner if blocks like this if (const std::unique_ptr<SettingsStore> settingsStore = std::make_unique<SettingsStore>(); settingsStore->IsEnabledPlugin(pluginName)) {

its harder to read, easier to accidentally break the if statement, and all around not an improvement in any fashion.

[shdwmtr]

Lots of these changes aren't inherently C++20 related, I'm not sure why they are apart of this PR. I was ready to merge it before you added all of these changes. We are just changing stuff for the sake of changing it.

[ninetailedtori]

Lots of these changes aren't inherently C++20 related, I'm not sure why they are apart of this PR. I was ready to merge it before you added all of these changes. We are just changing stuff for the sake of changing it.

ngl, let me move it to another pr. It's part of performance changes, but it's ok if you want me to revert the ones that fall outside of what we wanted.

[shdwmtr]

I was looking for the absolute bare minimum changes required to move to C++20, nothing else

[ninetailedtori]

I was looking for the absolute bare minimum changes required to move to C++20, nothing else

Some of these are genuine errors in C++20, and thus have to be moved to new behaviours. This PR was intended to be not just C++20, but making it faster in C++20 as well, through code generation rule changes in 20+.

[ninetailedtori]

Just cleaned up the majority of the Millennium backend, including finishing off any missing C++20 support or singleton rework bits, and any changes of spec that are required to build without errors. I need a test build in Windows though, Linux is flawless though.