fix: trust manual builds before checking libgomp - #437
Merged
esmuellert merged 3 commits intoJul 22, 2026
Conversation
richardgill
marked this pull request as ready for review
July 16, 2026 22:42
…to fix/manual-build-libgomp-detection
esmuellert
added a commit
that referenced
this pull request
Jul 22, 2026
…466) ## Summary De-flakes the `explorer_staging_spec.lua` test **"should refresh staged content when index changes"**, which was intermittently failing the **Release** workflow (both runs #457 and #437 failed on this exact test, only on the slower runners — `ubuntu-latest-x64`, `macos-latest-arm64`). Because `version-and-tag`/`release` depend on `build-and-test`, one flaky test blocks the whole release. ## Root cause — a test race The test wrote a new change to disk, called `view.update` (which re-renders asynchronously and **swaps** the modified buffer between working-tree and `:0`), then asserted the buffer content immediately after `wait_for_session_ready`: ```lua if not session.stored_diff_result then return false end -- only checks it's non-nil ``` `stored_diff_result` **persists from the previous view**, so the wait returns *before* the async re-render loads the new content. On loaded runners the assert reads stale content and `assert_contains(content, "change B")` fails. The content loads correctly a moment later — the test just checked too early. ## Fix (test-only) - **`tests/helpers.lua`** — add `wait_for_modified_content(tabpage, expected, timeout)`: unlike the fixed-bufnr `wait_for_buffer_content`, it **re-fetches the current modified buffer on every poll**, so it tolerates the working↔`:0` buffer swap. It waits until the buffer actually contains the expected text. - **`explorer_staging_spec.lua`** — poll at the three "change B" checkpoints (steps 3, 4, 5) before asserting. ## Proof (deterministic reproduction) Pinning nvim to a single CPU (`taskset -c 0`) reliably surfaces the race: | | Result | |---|---| | **Pre-fix** spec, 1 CPU | **2/10 flaked** (same failure as CI) | | **Fixed** spec, 1 CPU | **0/15 flaked** | So the fix is load-bearing, not just "passes on fast hardware." ## Notes - Test-only change; no production code touched. - Pre-existing on `main` — improves Release + build-and-test reliability for all PRs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Check for an unversioned, manually built native library before testing whether the system exposes
libgomp.On NixOS, a manual build can resolve
libgompthrough its RUNPATH even though the library is absent fromldconfig. The previous ordering therefore marked a valid manual build as needing an update.Versioned, prebuilt libraries continue to use the existing libgomp detection and bundling behavior.