[agorielikov]

Covers WIN-24580 by adding setting that allows builds to go though Incredibuild by default like in RustRover version and WIN-24581 by routing output though build window in CLion and Rider plugins.

[udif2025]

Nice work overall. Routing CLion builds through ProjectTaskRunner and replacing Rider's entry points makes sense, the fallback-with-notification is a real improvement over RustRover's old silent fallback, and the docs and changelog are updated. CI is green. Comments below, most important first.

Should fix

1. Windows NuGet and project-level MSBuild errors aren't recognised (CompilerOutputParser.MSVC_UNLOCATED). The optional origin prefix [^:\s][^:]*? can't contain a drive letter's colon. I ran the patterns against sample lines:

   • C:\src\App\App.csproj : error NU1101: Unable to find package Foo. [C:\src\App.sln]: matches nothing, with or without the 3> prefix.
   • The same line with a Linux path does match.
   • C:\...\App.csproj : warning NU1603: ... and code-less EXEC : error : something failed are missed too.

   Result: a failed restore on Windows shows "Build failed" with no entries in the build tree. Allowing an optional [A-Za-z]: at the start of the prefix (and optionally making the code optional) should fix it. Please add test cases.

2. RiderBeforeRunBuildOverride is registered for every Rider user, not only those with the setting on. Only executeTask checks accelerateIdeBuilds.

   • val rider = rider ?: return false: if a future Rider renames or moves BuildSolutionBeforeRunTaskProvider / BuildProjectBeforeRunTaskProvider, every .NET run configuration stops launching, even with the setting off. Please fail softly (log, and let the run proceed) instead.
   • createTask = null: the platform side checks out. RunManagerImpl.stringIdToBeforeRunProvider keeps the last provider for an id, so saved steps still load. But any Rider code that calls BeforeRunTaskProvider.getProvider(project, id)?.createTask(...) now gets null, which could silently drop the default Build Project step from new run configurations. Please check manually that a brand-new .NET run configuration still gets its Build step, with the setting both on and off.

Please verify

3. cmake-support.xml ordering: order="first, before CMakeProjectTaskRunner". The before part only works if CLion registers its runner with id="CMakeProjectTaskRunner". Otherwise only first applies, and CLion's runner is also first, so which one runs first isn't defined. Please confirm in CLion that Build really goes through Incredibuild.
4. IncredibuildInstallation.queryLicensed: a non-zero exit from /QueryLicense counts as "unknown", which is treated as Ready. Does BuildConsole exit non-zero when there's no licence? If so, unlicensed machines will try to accelerate instead of falling back.
5. RiderBuildActionOverride fallback replays Rider's action with the original click's context. When the build turns out to be NotPrepared, the saved e.dataContext is reused later in invokeLater. For Build Selection, the Solution Explorer selection may have changed by then. Consider capturing what's needed up front, or reporting the failure instead of replaying.
6. Rider can show a "Checking Incredibuild" modal on Build up to every 5 minutes. The check runs under runProcessWithProgressSynchronously, the cache expires after 5 minutes (CACHE_TTL_MS), and the startup warm-up only runs when the setting was already on at project open. So the first Build after each expiry waits on BuildConsole behind a modal dialog. Consider refreshing the cache in the background and using cachedStatus when the action runs.

Low / nits

• IncredibuildCMakeProjectTaskRunner.run: the catch-all hands everything back to CLion even after a planned build has finished (index > 0), so work gets built twice. Apply the same index == 0 guard used for NotPrepared.
• IncredibuildProjectTaskRunner (Cargo) still calls awaitNoBuildRunning and creates the build separately, so the new buildStartLock doesn't cover it. Either use startWhenNoBuildRunning there too, or reword the KDoc. Also, whenNoBuildRunning now runs start() (console and tool window setup) on the EDT while holding the lock, so the EDT can briefly wait while a background build spawns its process.
• IncredibuildConfigurable.showInstallation: if check() throws inside the executor, the label stays on "Checking..." forever. Wrap it and show the error.
• IncredibuildConfigurable.hasCMake checks the com.intellij.cmake plugin id, which also exists outside CLion, so the checkbox may show where it does nothing. Gating on an action id from cmake-support.xml, as RIDER_ACTION_ID does for Rider, would match how it's loaded.
• No minimum version for CLion and Rider builds: AcceleratedBuildTool.NATIVE.minimumVersion is null, so the "unsupported version" fallback from WIN-24580 can never trigger there. Fine if intended; worth confirming with product.
• IdeBuildView counts each duplicate diagnostic once. That correctly collapses MSBuild's closing summary, but a header warning hit by 30 source files shows up as "1 warning".
• ide_build_fallback is captured on every fallback build, even when the notification is suppressed. Fine if intended; just be aware of the volume.
• rider-support.xml hardcodes English text / description for BuildWholeSolutionAction, which loses Rider's localisation.
• README / CHANGELOG: "an accelerated build of the IDE's own reports…" reads oddly.
• The PR covers WIN-24580 and WIN-24581. Please make sure both tickets are linked.

This review is based on the diff and the platform source; nobody has run the plugin in CLion or Rider yet. Items 2–6 need a manual pass in the IDEs.

[udif2025]

Thanks for the quick turnaround. The fixes look good. Here's where each point from the first review stands.

Fixed

• NuGet and project-level MSBuild errors: recognised now, and there are tests. I ran the new patterns and C:\…\App.csproj : error NU1101, EXEC : error : … and the 3> prefix all match. Moving TOOL_UNLOCATED ahead so clang: keeps its name is a good catch.
• Rider before-launch override when Rider's provider is missing: it now logs and lets the run go ahead, and canExecuteTask agrees with that.
• /QueryLicense with a non-zero exit code: InitiatorRegType None is now treated as no licence whatever the exit code.
• "Checking Incredibuild" modal every 5 minutes: checkForIdeBuild now uses the cached result and refreshes in the background, and turning the setting on warms the cache too.
• CMake partial build handed back to CLion: builtAny now prevents the second build.
• Build lock: the process is created under the lock and the console is set up outside it. The Cargo gap is documented in the KDoc.
• Settings label stuck on "Checking...": errors are shown now.
• hasCMake: now gated on Incredibuild.CMake.Build, which I confirmed exists in cmake-support.xml.
• Warning counts: each occurrence is counted, the tree shows each one once, and MSBuild's summary is skipped.
• Localisation and README wording: fixed.

New comments (minor)

1. Build Selection fallback: the selection check may never trigger (RiderBuildActionOverride). sameSelection re-reads the selection from the saved e.dataContext. On current platforms that is a snapshot taken when the action ran, so it will probably always return the original selection, and the "selection has changed" branch would never run. That also means the replay would still build what was originally asked, which is the right result. If the snapshot assumption holds, the check can be dropped. If it doesn't hold, the check is useful. Either way, please confirm which it is.
2. resource-bundle="messages.RiderActionsBundle": please confirm in Rider that the bundle name and the action.BuildWholeSolutionAction.text / .description keys exist. If either is missing, Build Solution would show a key or empty text in the menu and on the toolbar.
3. The parser is slightly broader now that the code is optional. For example, Test #3: error: assertion failed (CTest output) now becomes a build error. That's probably acceptable, but worth knowing.
4. The MSBuild summary skip depends on Time Elapsed following Build succeeded. / Build FAILED.. If something else prints that start line without the end line, any later diagnostics are hidden. This is low risk, but a test for the summary skip would help.

Still open from the first review (not code changes)

• A manual pass in Rider: a new .NET run configuration should still get its Build step, with the setting both on and off.
• A manual pass in CLion: Build should really go through Incredibuild, which confirms that the before CMakeProjectTaskRunner ordering works.
• Product confirmation that CLion and Rider builds need no minimum Incredibuild version.