Currently to access the SP register, RegRead and RegWrite rely on a
out-of-bounds array access to reach the next element in a struct. As
of writing only git versions of GCC catch this error.
Specify the SP register when we want to access it in these functions.
The latest git version of GCC has issues with my diamond inheritance
shenanigans. Since that's now two compilers that don't like it I thought
it'd be best to just axe all of it and just have the two templates like
before.
This rolls the features of BasicRangedSetting into BasicSetting, and
likewise RangedSetting into Setting. It also renames them from
BasicSetting and Setting to Setting and SwitchableSetting respectively.
Now longer name corresponds to more complex thing.
In testing future versions of Qt I forgot to compile with `YUZU_USE_QT_WEB_ENGINE`, so with that flag enabled there are two issues that cropped up.
1. yuzu currently uses setRequestInterceptor, added in Qt 5.6, deprecated in 5.13 with this explaination at https://doc.qt.io/qt-5/qwebengineprofile-obsolete.html
Interceptors installed with this method will call QWebEngineUrlRequestInterceptor::interceptRequest on the I/O thread. Therefore the user has to provide thread-safe interaction with the other user classes. For a duration of this call ui thread is blocked. Use setUrlRequestInterceptor instead.
2. QWebEngineSettings::globalSettings() pointer no longer exists in later versions of Qt
From what I can tell, QtNXWebEngineView doesn't need to set these globally,
when we make changes to settings(), QtWebEngineView::page() creates the page
object if it doesn't exist yet. I don't see the page object being destroyed
or otherwise replaced, except via destroying the QtNXWebEngineView object.
The globalSettings() make sense if Pages or Views objects are being
created outside of yuzu's control.
To test this I've compared what BrowseNX and Odyssey's Action guide do in mainline 1049 and this PR.
For now we're going to go up the chain to QWebEngineProfile::defaultProfile()->settings()
lat9nq