[llvm] [cmake] Fix the dead VSINSTALLDIR check in FindDIASDK (PR #217071)

Larry Meadows via llvm-commits llvm-commits at lists.llvm.org
Sat Aug 29 11:27:15 PDT 2026


lfmeadow wrote:

Closing this: #218499 landed the detection fix on its own, so the problem that motivated this PR is gone.

@rnk — to answer your question, yes, dropping the `VSINSTALLDIR` inference would have resolved it, and I still think requiring an explicit path is the cleaner rule. But it has stopped being mine to propose. #218499 repaired that inference deliberately, because the 23.1.0 RC builds were shipping without DIA (`llvm-pdbutil diadump` failing on them), and it was cherry-picked to `release/23.x`. Removing the inference now would take that back out from under a release, so it wants agreement from @Nerixyz, @petrhosek and @compnerd rather than a PR from me.

Worth recording for whoever next looks at this: the breakage that caused the revert in #209137 has not recurred. Five days on, `lldb-x86_64-win` and `lldb-aarch64-windows` are both green. DIA is being enabled from the environment on at least one bot — `llvm-clang-x86_64-expensive-checks-win` is now linking `diaguids.lib` — and nothing has failed because of it. That bot is red, but it was red on and off for days beforehand and it is failing on `LNK1102: out of memory` during linking, not on DIA. So the `msdia140.dll` concern this PR was built around is still only a latent one.

Two loose ends survive this PR and are free for the taking:

- `CMake.md` says `LLVM_ENABLE_DIA_SDK` "Defaults to ON". It has always defaulted to `${DIASDK_FOUND}`.
- Nothing yet distinguishes an SDK that was pointed at from one that merely turned up in the environment, so `-DLLVM_ENABLE_DIA_SDK=OFF` is the only way to decline it.

Thanks for the review.

https://github.com/llvm/llvm-project/pull/217071


More information about the llvm-commits mailing list