Fix Windows CI: update swift-docc-plugin to 1.4.6

[leogdion]

Summary

• Updates swift-docc-plugin from 1.4.5 → 1.4.6 in Package.resolved

Problem

Windows CI (windows-2022 and windows-2025) was failing with:

error: cannot find 'Lock' in scope
error: cannot find type 'SnippetExtractor' in scope
error: cannot find type 'ParsedSymbolGraphArguments' in scope

The root cause: swift-docc-plugin uses a Symbolic Links/ directory to share source files across plugin targets. On Windows, without proper .gitattributes, git checks these symlinks out as plain text files (containing just the path string). The Swift compiler then tries to compile these empty stubs, producing missing-type errors.

Fix

swift-docc-plugin 1.4.6 release notes: "Add .gitattributes for symlinks on Windows." — this ensures git resolves symlinks to real source files on Windows checkouts.

Package.swift already declares from: "1.4.0", so only Package.resolved needed updating.

Test plan

• Build on Windows (windows-2022) passes
• Build on Windows (windows-2025) passes

🤖 Generated with Claude Code

---

Perform an AI-assisted review on

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 9252f1a2-3a8f-4c90-9ee4-3b3ab28269ea

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/windows-docc-plugin-symlinks

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Code Review

Summary

This PR consolidates three separate fixes:

1. swift-docc-plugin 1.4.5 → 1.4.6 (Windows symlink fix)
2. CI workflow optimization with dynamic matrix + new jobs (from Optimize CI workflows with dynamic matrix and cache cleanup #129)
3. Android/WASM doc test path resolution (from Fix Android doc test path resolution #130)

Note: PRs #131 and #132 are from the same branch (fix/windows-docc-plugin-symlinks). #131 appears to be a duplicate — recommend closing it.

---

Issues

🔴 Windows matrix: include entries missing runs-on

The Windows build matrix has three include entries (swift-6.3-release, swift-6.2-release, swift-6.1-release) that don't include a runs-on key:

matrix:
  runs-on: [windows-2022, windows-2025]
  include:
    - swift-version: swift-6.3-release
      swift-build: 6.3-RELEASE
    - swift-version: swift-6.2-release
      swift-build: 6.2-RELEASE
    - swift-version: swift-6.1-release
      swift-build: 6.1-RELEASE

In GitHub Actions, include entries that don't match any existing matrix dimension are appended as new standalone jobs. Since these entries lack runs-on, the jobs will have an undefined ${{ matrix.runs-on }} and fail at the runner allocation step. The intent appears to be running all 3 Swift versions × 2 Windows runners = 6 combinations. To achieve that, the matrix needs to be restructured:

matrix:
  runs-on: [windows-2022, windows-2025]
  swift-version: [swift-6.3-release, swift-6.2-release, swift-6.1-release]
  include:
    - swift-version: swift-6.3-release
      swift-build: 6.3-RELEASE
    - swift-version: swift-6.2-release
      swift-build: 6.2-RELEASE
    - swift-version: swift-6.1-release
      swift-build: 6.1-RELEASE

(Note: the old matrix had the same pattern, so if Windows CI was passing before it's worth verifying actual behavior.)

🟡 build-macos passes undefined matrix variables to swift-build

The minimal build-macos job has only one matrix entry (no type, deviceName, osVersion, download-platform), but still passes these to the action:

with:
  type: ${{ matrix.type }}
  deviceName: ${{ matrix.deviceName }}
  osVersion: ${{ matrix.osVersion }}
  download-platform: ${{ matrix.download-platform }}

Undefined matrix variables evaluate to empty strings. This is probably fine if swift-build@v1.5.2 handles empty inputs gracefully, but it's worth confirming — otherwise move those with: params to build-macos-full only.

🟡 docs and lint gates on build-android

needs: [build-ubuntu, build-macos, build-windows, build-macos-full, build-android]

build-android only runs when full-matrix == 'true' (main/PR branches), and the condition is !cancelled() && !failure(). On feature branches where build-android is skipped, its status will be skipped (not success). The !failure() guard handles this correctly — skipped jobs don't count as failures — so this should work, but it's worth a quick sanity check on a feature-branch push.

🟡 actions/checkout@v6 — verify this version exists

All jobs reference actions/checkout@v6. As of this review, the latest published major version of actions/checkout is v4. If v6 doesn't exist, all jobs will fail immediately with a version-not-found error. Please verify this is intentional (perhaps a pre-release or internal version).

---

Positive Notes

• Dynamic matrix configuration is a clean approach — avoids duplicating entire job definitions for feature vs. main branches.
• Concurrency groups with cancel-in-progress: true are a good addition that reduce wasted CI minutes.
• paths-ignore for docs/markdown is appropriate; pure doc changes shouldn't re-run the full suite.
• Cache cleanup workflows (cleanup-caches.yml, cleanup-pr-caches.yml) are well-implemented with proper actions: write permissions scoped to the job.
• CodeQL workflow is a straightforward addition with appropriate scheduling.
• Settings.swift 3-strategy fallback for projectRoot is well-structured and clearly commented. Using FileManager.default.currentDirectoryPath before falling back to #filePath is the right priority order for cross-platform support.
• Platform-conditional docPaths cleanly separates Android/WASI constraints from the default full path set.
• The resolveFilePath Android guard (returning the path as-is) mirrors the flat directory copy structure correctly.

---

Test Coverage

The scope of this PR is CI infrastructure and path resolution, not library logic. The Settings.swift changes are tested implicitly by the documentation tests passing on each platform. No additional unit tests are needed, but the test plan in the PR description (Windows CI passing) should be verified before merge.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.13%. Comparing base (18c1e25) to head (99edc26).

Additional details and impacted files

@@            Coverage Diff             @@
##           v0.0.4     #132      +/-   ##
==========================================
- Coverage   78.16%   78.13%   -0.03%     
==========================================
  Files         126      126              
  Lines        5651     4555    -1096     
==========================================
- Hits         4417     3559     -858     
+ Misses       1234      996     -238     

Flag	Coverage Δ
spm	77.89% <ø> (+0.33%)	⬆️
swift-	?
swift-6.0	77.87% <ø> (?)
swift-6.1	77.95% <ø> (?)
swift-6.2	77.87% <ø> (?)
swift-6.3	78.04% <ø> (?)
ubuntu	78.13% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[claude]

Code Review: Fix Windows CI - update swift-docc-plugin to 1.4.6

The Package.resolved update is the right fix — swift-docc-plugin 1.4.6 adds .gitattributes for symlink handling on Windows, which directly addresses the missing-type compile errors.

Duplicate PR notice

This PR (132) and PR 131 are both from the same branch 'fix/windows-docc-plugin-symlinks' targeting different bases:

• PR 132 targets 'v0.0.4'
• PR 131 targets '128-workflow-updates'

This means PR 132's diff includes all the CI workflow changes from PR 129 in addition to the Package.resolved bump. Consider whether this release branch should receive the workflow changes as well, or if only the Package.resolved fix should be cherry-picked. One of the two PRs should be closed to reduce confusion.

The fix itself

Correct and minimal. No source changes required since Package.swift already declares 'from: "1.4.0"'.