README's LLVM version guidance is stale — LLVM 19+ isn't uniformly safe (see #659)
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 70/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- rust
- Domain
- documentation
Research direction
Start with the quoted libclang guidance in the README and compare it with the LLVM findings in #659, including the fix referenced by commit 21ec8f8. Done means the README no longer implies LLVM 19+ is broadly safe and instead states a verified-good range or points readers to #659 for current version guidance.
Written by the indexing model from the issue text.
Description
Description
The README's libclang guidance currently reads:
- Binding generation via
bindgenrequireslibclang. The easiest way to acquire this is viawinget
This framing (last updated for the LLVM 18 / ARM64 __prefetch bug) reads as "LLVM 19+ is fine," but #659 shows a different, broader regression on x86_64 (not ARM64-specific) that affects newer LLVM through at least 23.1.1 — confirmed independently in a comment on #659 with LLVM 23.1.1 producing ~40 opaque 1-byte struct stubs for core WDK types (_DEVICE_OBJECT, _IRP, _DRIVER_OBJECT, etc.) on a WDM driver. #659's reporters found LLVM 21.1.2 works; I found LLVM 17.0.6 works; neither of us tried the full range in between, so the actual good/bad boundary isn't pinned down yet.
Suggested fix
Once wdk-sys/wdk-build ship a release including the fix already on main (referenced in #659, commit 21ec8f8), update the README to either:
- State the actual verified-good LLVM range (once known), or
- Point directly at #659 for current known-good/known-bad LLVM versions until a release resolves it, rather than implying the fix is scoped to "LLVM 19+" (which is true for the ARM64
__prefetchbug this section originally documented, but not for the newer x86_64 regression).
This is a docs-accuracy issue, not a functional bug — filing separately from #659 since #659 already has the technical repro/fix info; this is specifically about updating README guidance so new users don't get steered wrong by the "LLVM 19+ is fine" implication.
- Dominant language
- Rust
- Stars
- 1.9k
- Forks
- 136
- Avg merge
- 7d 7h
- Merged PRs (30d)
- 4
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/windows-drivers-rs
-
enhancement next-release-priority
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
microsoft/windows-drivers-rs#646 ·
-
Separate out integration test for cargo wdk build for the case when certificate is already present Openenhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
microsoft/windows-drivers-rs#488 ·
-
Difficulty 5/5 Over a week Newbie friendliness 38/100
microsoft/windows-drivers-rs#731 · 1 comment · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
microsoft/windows-drivers-rs#724 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
microsoft/windows-drivers-rs#712 · 1 comment ·
All issues in microsoft/windows-drivers-rs
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100