Skip to content

chore: upstream merge 2509#50

Open
NikhilNarayana wants to merge 1029 commits intoslippifrom
upstream-merge-2509
Open

chore: upstream merge 2509#50
NikhilNarayana wants to merge 1029 commits intoslippifrom
upstream-merge-2509

Conversation

@NikhilNarayana
Copy link
Member

No description provided.

NikhilNarayana and others added 30 commits November 8, 2025 02:25
…erface

Android: Replace Action1 helper with Kotlin lambda
…_overwriting_debug_verbosity_in_release_builds

Logging: Don't overwrite LDEBUG level in Release builds
Co-Authored-By: OatmealDome <julian@oatmealdome.me>
… ConfigChangedCallbackID

Co-authored-by: OatmealDome <julian@oatmealdome.me>
…eanups

StringUtil: Cleanups and add some character encoding conversion unit tests.
Keeps Kotlin formatting consistent with standard Kotlin style guides.
We can now route Android analytics through Common::HttpAnalyticsBackend, drop the Volley sender, and keep the JNI layer limited to only transfer metadata since https://bugs.dolphin-emu.org/issues/11772 has been fixed.
…n-setting-change

DolphinAnalytics: Reload backend when config changes
…ig-kotlin-style

.editorconfig: Add Kotlin indentation rule
…-analytics

Android: Use the shared HTTP analytics backend
…age-kotlin

Android: Convert AlertMessage dialog to Kotlin
…settings-android

Android: Add Reset Dolphin Settings functionality
Trigraphs support is generally disabled by default, but some compilers
(e.g. GCC) may still warn when one hypothetical trigraph is encountered.

For example, one of these warnings was introduced as part of dolphin-emu#14067:

```
.../Source/Core/DolphinQt/MainWindow.cpp:1433:77: warning: trigraph ??) ignored, use -trigraphs to enable [-Wtrigraphs]
 1433 |       this, tr("Select a File"), dialog_path, tr("All Save States (*.sav *.s??);; All Files (*)"));
      |
.../Source/Core/DolphinQt/MainWindow.cpp:1445:77: warning: trigraph ??) ignored, use -trigraphs to enable [-Wtrigraphs]
 1445 |       this, tr("Select a File"), dialog_path, tr("All Save States (*.sav *.s??);; All Files (*)"));
      |
```

The warning is generally not interesting and has been disabled now.
If bind was called more than once for a SwitchSettingViewHolder, the
line `binding.settingSwitch.isChecked = setting.isChecked` would
accidentally trigger the listener registered during the previous bind
call.
… default value ConfigChangedCallbackID

Co-Authored-By: OatmealDome <OatmealDome@users.noreply.github.com>
Tapping outside the System Update dialog would previously close it and leave the update in a partially canceled, inconsistent state. This change disables outside-touch dismissal to avoid accidental interruptions and ensure the process completes cleanly.
…ackID-size_t-fix

CPUThreadConfigCallback: Use maximum value of size_t instead of -1 as default value ConfigChangedCallbackID
… shared a read/write position making them effectively not thread-safe.
SettingsWindow: Set navigation list stylesheet in constructor
…ersion

CMake: Allow both glslang 15 and 16
jordan-woyak and others added 30 commits November 27, 2025 14:30
…ements-eternal-darkness-testing-my-sanity

RetroAchievements - Remove Hardcore Check from ApplyMemoryPatch
We have an optimization where the guest carry flag is kept in the host
carry flag between certain back-to-back pairs of integer instructions.
If the second instruction falls back to the interpreter, then
FallBackToInterpreter should flush the carry flag to m_ppc_state,
otherwise the interpreter reads a stale carry flag and at some later
point Jit64 trips the "Attempt to modify flags while flags locked!"
assertion.

An alternative solution would be to not store the guest carry flag in
the host carry flag to begin with if we know the next instruction is
going to fall back to the interpreter, but knowing that in advance is
non-trivial. Since interpreter fallbacks aren't exactly intended to be
super optimized, I went for the flushing solution instead, which is how
JitArm64 already works. In most cases, the emitted code shouldn't even
differ between these two solutions.

Note that the problematic situation only happens if the first integer
instruction doesn't fall back to the interpreter but the second one
does. This used to be impossible because there's no "JIT disable"
setting that's granular enough to disable some integer instructions but
not all, but with the constant propagation PR, it's possible if constant
propagation is able to entirely evaluate the first instruction but not
the second.
Aside from being unnecessary, on Windows the flag prevents two instances
of Dolphin (one instance from before 2509-371 when the flag was
introduced and the other after) from running the same ROM
simultaneously.

Attempting to do so generated the false error `"[Rom]" is an invalid
GCM/ISO file, or is not a GC/Wii ISO.` followed by `Failed to init core`
and emulation shutdown on the second instance to start the game. Fixing
the incorrect error message is a task I'm deferring to another PR.

The problem didn't happen when both instances were 2509-371 or later,
but I ran into it while bisecting an issue and it'd be nice to avoid
that problem in the future.
…dont_request_delete_access_for_read_only_open

Windows/DirectIOFile: Don't request DELETE access for read-only Open
…-vertex-rounding

GameSettings: Enable VertexRounding in Frogger: Ancient Shadow.
Recently came across a strange issue where Dolphin would hard crash in most games with this error:

```sh
/usr/include/c++/15.2.1/optional:1165: constexpr const _Tp* std::optional<_Tp>::operator->() const [with _Tp = InputCommon::ImagePixelData]: Assertion 'this->_M_is_engaged()' failed.
```

The culprit turned out to be accessing `host_key_image` which is an `std::optional` thay may return `std::nullopt`. I'm not sure why this issue started occuring for me since I've had no issue with my Dynamic Input Textures in the past? But this fixes a crash if the image fails to load.
…rning-size

DolphinQt: Use QtUtils::CreateIconWarning to make the RetroAchievements warning size consistent with other warnings.
Jit64: Flush carry flag in FallBackToInterpreter
DITConfiguration: Prevent a crash if images fail to load
…assing_immediate_to_non_immediate_parameter

Jit64: Avoid passing immediate to non-immediate parameter
If we're on an x64 CPU that doesn't have the MOVBE extension, trying to
SwapAndStore a host register results in that register's value getting
clobbered with the swapped value. Jit64::stX and Jit64::stXx detect this
case, and if necessary, emit a MOV to a register that's fine to clobber.

This logic was broken by the merge of PR 12134. Jit64::stX and
Jit64::stXx were assuming that if RegCache::IsImm returns true for a
guest register, calling RegCache::Use or RegCache::BindOrImm for that
guest register would result in an immediate. However, PR 12134 made it
possible for a guest register to have both a host register and an
immediate in the register cache at the same time. When this happens,
RegCache::IsImm returns true, yet RegCache::Use and RegCache::BindForImm
return an RCOpArg whose Location returns a host register. (To make it
extra confusing, RCOpArg::IsImm calls RegCache::IsImm if the RCOpArg
came from RegCache, so RCOpArg::IsImm returns true!)

To fix this, in cases where Jit64::stX and Jit64::stXx explicitly need
an immediate to avoid having to emit an extra MOV, let's call
RegCache::Imm32 so that we're certain that we're getting an immediate.

This fixes an issue on older x64 CPUs that manifested as e.g. completely
broken graphics in Spyro: Enter the Dragonfly.
…ing when Dolphin is configured to use the adapter.
…r-imm

Jit64: Explicitly get imm for clobbered stores
mingw: fix usage of std::invocable with EnumerateRadios
This function is unused.
Without it, the game crashes after completing the tutorial level.
GameSettings: Enable MMU for Vexx (PAL)
…abs2spaces

StringUtils: Drop TabsToSpaces
…hint

ControllerInterface: Turn off SDL's GameCube controller adapter handling when Dolphin is configured to use the adapter.
MainWindow: Fix sscanf type/width specifiers for DWORD
- update to macos-15-intel runners (last time intel runners will be available)
- allow old 3.5 cmake policy (work is being done by upstream to fix this)
- builds still run on macOS 14
Release for December 2025

slippi notes:
- LogManager.cpp: m_level is gone and basically replaced with GetEffectiveLogLevel()
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.