Skip to content

[WindowsDriver] Always consider WinSdkVersion #130377

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Mar 12, 2025

Conversation

Steelskin
Copy link
Contributor

Currently, the -Xmicrosoft-windows-sdk-version is only used if -Xmicrosoft-windows-sdk-root is also provided. This is a surprising behavior since the argument should still be taking effect if LLVM uses the Windows SDK root from the registry.

Tested locally in a simple Hello World program including Windows.h and compiled with -Xmicrosoft-windows-sdk-version 10.0.18362.0 on a system where the SDK 10.0.22621.0 is also installed and verified that the correct header was included.

Currently, the `-Xmicrosoft-windows-sdk-version` is only used if
`-Xmicrosoft-windows-sdk-root` is also provided. This is a surprising
behavior since the argument should still be taking effect if LLVM uses
the Windows SDK root from the registry.

Tested locally in a simple Hello World program including `Windows.h` and
compiled with `-Xmicrosoft-windows-sdk-version 10.0.18362.0` on a system
where the SDK 10.0.22621.0 is also installed and verified that the
correct header was included.
Copy link

github-actions bot commented Mar 8, 2025

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

@llvmbot
Copy link
Member

llvmbot commented Mar 8, 2025

@llvm/pr-subscribers-clang-driver

@llvm/pr-subscribers-platform-windows

Author: Fabrice de Gans (Steelskin)

Changes

Currently, the -Xmicrosoft-windows-sdk-version is only used if -Xmicrosoft-windows-sdk-root is also provided. This is a surprising behavior since the argument should still be taking effect if LLVM uses the Windows SDK root from the registry.

Tested locally in a simple Hello World program including Windows.h and compiled with -Xmicrosoft-windows-sdk-version 10.0.18362.0 on a system where the SDK 10.0.22621.0 is also installed and verified that the correct header was included.


Full diff: https://github.com/llvm/llvm-project/pull/130377.diff

1 Files Affected:

  • (modified) llvm/lib/WindowsDriver/MSVCPaths.cpp (+19-6)
diff --git a/llvm/lib/WindowsDriver/MSVCPaths.cpp b/llvm/lib/WindowsDriver/MSVCPaths.cpp
index a7bffbb20eba1..60fc096059c62 100644
--- a/llvm/lib/WindowsDriver/MSVCPaths.cpp
+++ b/llvm/lib/WindowsDriver/MSVCPaths.cpp
@@ -85,11 +85,22 @@ getHighestNumericTupleInDirectory(llvm::vfs::FileSystem &VFS,
   return Highest;
 }
 
-static bool getWindows10SDKVersionFromPath(llvm::vfs::FileSystem &VFS,
-                                           const std::string &SDKPath,
-                                           std::string &SDKVersion) {
+static bool getWindows10SDKVersionFromPath(
+    llvm::vfs::FileSystem &VFS, const std::string &SDKPath,
+    std::optional<llvm::StringRef> WinSdkVersion, std::string &SDKVersion) {
   llvm::SmallString<128> IncludePath(SDKPath);
   llvm::sys::path::append(IncludePath, "Include");
+
+  if (WinSdkVersion) {
+    // Use the provided version, if it exists.
+    llvm::SmallString<128> VersionIncludePath(IncludePath);
+    llvm::sys::path::append(VersionIncludePath, *WinSdkVersion);
+    if (VFS.exists(VersionIncludePath)) {
+      SDKVersion = *WinSdkVersion;
+      return true;
+    }
+  }
+
   SDKVersion = getHighestNumericTupleInDirectory(VFS, IncludePath);
   return !SDKVersion.empty();
 }
@@ -122,7 +133,8 @@ static bool getWindowsSDKDirViaCommandLine(
     if (!SDKVersion.empty()) {
       Major = SDKVersion.getMajor();
       Version = SDKVersion.getAsString();
-    } else if (getWindows10SDKVersionFromPath(VFS, Path, Version)) {
+    } else if (getWindows10SDKVersionFromPath(VFS, Path, WinSdkVersion,
+                                              Version)) {
       Major = 10;
     }
     return true;
@@ -444,7 +456,8 @@ bool getWindowsSDKDir(vfs::FileSystem &VFS, std::optional<StringRef> WinSdkDir,
     return !WindowsSDKLibVersion.empty();
   }
   if (Major == 10) {
-    if (!getWindows10SDKVersionFromPath(VFS, Path, WindowsSDKIncludeVersion))
+    if (!getWindows10SDKVersionFromPath(VFS, Path, WinSdkVersion,
+                                        WindowsSDKIncludeVersion))
       return false;
     WindowsSDKLibVersion = WindowsSDKIncludeVersion;
     return true;
@@ -475,7 +488,7 @@ bool getUniversalCRTSdkDir(vfs::FileSystem &VFS,
           Path, nullptr))
     return false;
 
-  return getWindows10SDKVersionFromPath(VFS, Path, UCRTVersion);
+  return getWindows10SDKVersionFromPath(VFS, Path, WinSdkVersion, UCRTVersion);
 }
 
 bool findVCToolChainViaCommandLine(vfs::FileSystem &VFS,

Copy link
Member

@compnerd compnerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if we should do this check this way. Similar to the other arguments if the user specifies the value, we should assume that it is correct rather than basing it on a check that the path exists.

@compnerd compnerd added the clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' label Mar 8, 2025
@compnerd compnerd requested a review from rnk March 8, 2025 06:42
Skip checking that the directory actually exists, trust the user input.
@Steelskin
Copy link
Contributor Author

I'm not sure if we should do this check this way. Similar to the other arguments if the user specifies the value, we should assume that it is correct rather than basing it on a check that the path exists.

Thanks, I changed it so we always just use the user-provided version.

@Steelskin Steelskin requested a review from compnerd March 10, 2025 22:53
Copy link
Contributor Author

@Steelskin Steelskin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be happy to redo the static functions in this file to take pointers to the arguments rather than pass by reference. It makes it confusing to see which call modifies what.
But I have no idea what the LLVM style recommends.

@Steelskin Steelskin requested a review from compnerd March 10, 2025 23:16
@compnerd compnerd requested a review from zmodem March 11, 2025 00:49
@mstorsjo
Copy link
Member

Do we have any tests for these codepaths, and if not, would it be feasible to add some?

@compnerd
Copy link
Member

Do we have any tests for these codepaths, and if not, would it be feasible to add some?

I think that I convinced myself that there is no good way to test this. The reason is that we want to honour -Xmicrosoft-windows-sdk-version without -Xmicrosoft-windows-sdk-root. When doing so, we would rely on the system lookup. Testing without -Xmicrosoft-windows-sdk-root implies that we would need to ensure that the machine has a very specific shape and makes the tests non-portable. It is unclear to me if that is worth it.

@compnerd
Copy link
Member

Spoke with @mstorsjo "offline" - came to agreement that this is difficult to test.

@Steelskin
Copy link
Contributor Author

Do we have any tests for these codepaths, and if not, would it be feasible to add some?

As @compnerd mentioned, this is relying on the installation environment. Does LLVM have test facilities for faking the registry and the file system? Otherwise, this is going to require a refactor of this file so we can inject a fake Windows SDK installation path for testing purposes.

@compnerd compnerd merged commit 606e9fa into llvm:main Mar 12, 2025
11 checks passed
Copy link

@Steelskin Congratulations on having your first Pull Request (PR) merged into the LLVM Project!

Your changes will be combined with recent changes from other authors, then tested by our build bots. If there is a problem with a build, you may receive a report in an email or a comment on this PR.

Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail here.

If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of LLVM development. You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are working as expected, well done!

@llvm-ci
Copy link
Collaborator

llvm-ci commented Mar 12, 2025

LLVM Buildbot has detected a new failure on builder sanitizer-aarch64-linux-bootstrap-msan running on sanitizer-buildbot9 while building llvm at step 2 "annotate".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/94/builds/5181

Here is the relevant piece of the build log for the reference
Step 2 (annotate) failure: 'python ../sanitizer_buildbot/sanitizers/zorg/buildbot/builders/sanitizers/buildbot_selector.py' (failure)
...
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:512: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:512: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:512: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:512: note: using ld.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/ld.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:512: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:512: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:512: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/main.py:72: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 87023 tests, 72 workers --
Testing: 
FAIL: Clang :: Analysis/ftime-trace.cpp (912 of 87023)
******************** TEST 'Clang :: Analysis/ftime-trace.cpp' FAILED ********************
Exit Code: 1

Command Output (stderr):
--
RUN: at line 1: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/clang -cc1 -internal-isystem /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/lib/clang/21/include -nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -analyzer-checker=core /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/clang/test/Analysis/ftime-trace.cpp -ftime-trace=/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.raw.json -ftime-trace-granularity=0 -verify
+ /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/clang -cc1 -internal-isystem /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/lib/clang/21/include -nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -analyzer-checker=core /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/clang/test/Analysis/ftime-trace.cpp -ftime-trace=/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.raw.json -ftime-trace-granularity=0 -verify
RUN: at line 2: "/usr/bin/python3" -c 'import json, sys; print(json.dumps(json.load(sys.stdin), indent=4))' < /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.raw.json > /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.formatted.json
+ /usr/bin/python3 -c 'import json, sys; print(json.dumps(json.load(sys.stdin), indent=4))'
RUN: at line 3: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/FileCheck --input-file=/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.formatted.json --check-prefix=CHECK /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/clang/test/Analysis/ftime-trace.cpp
+ /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/FileCheck --input-file=/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.formatted.json --check-prefix=CHECK /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/clang/test/Analysis/ftime-trace.cpp
/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/clang/test/Analysis/ftime-trace.cpp:34:11: error: CHECK: expected string not found in input
// CHECK: "name": "Total CheckerManager::runCheckersForStmt (Pre)",
          ^
/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.formatted.json:2474:3: note: scanning from here
 }
  ^
/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.formatted.json:2638:2: note: possible intended match here
 "name": "Total CheckerManager::runCheckersForStmt (Post)",
 ^

Input file: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.formatted.json
Check file: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/clang/test/Analysis/ftime-trace.cpp

-dump-input=help explains the following input dump.

Input was:
<<<<<<
            .
            .
            .
         2469:  "dur": 1595, 
         2470:  "name": "Total dispatchWorkItem PostStmt", 
         2471:  "args": { 
         2472:  "count": 31, 
         2473:  "avg ms": 0 
         2474:  } 
check:34'0       X error: no match found
Step 11 (stage2/msan check) failure: stage2/msan check (failure)
...
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:512: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:512: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:512: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:512: note: using ld.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/ld.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:512: note: using lld-link: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/lld-link
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:512: note: using ld64.lld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/ld64.lld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/llvm/config.py:512: note: using wasm-ld: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/wasm-ld
llvm-lit: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/llvm/utils/lit/lit/main.py:72: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 87023 tests, 72 workers --
Testing: 
FAIL: Clang :: Analysis/ftime-trace.cpp (912 of 87023)
******************** TEST 'Clang :: Analysis/ftime-trace.cpp' FAILED ********************
Exit Code: 1

Command Output (stderr):
--
RUN: at line 1: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/clang -cc1 -internal-isystem /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/lib/clang/21/include -nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -analyzer-checker=core /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/clang/test/Analysis/ftime-trace.cpp -ftime-trace=/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.raw.json -ftime-trace-granularity=0 -verify
+ /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/clang -cc1 -internal-isystem /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/lib/clang/21/include -nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -analyzer-checker=core /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/clang/test/Analysis/ftime-trace.cpp -ftime-trace=/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.raw.json -ftime-trace-granularity=0 -verify
RUN: at line 2: "/usr/bin/python3" -c 'import json, sys; print(json.dumps(json.load(sys.stdin), indent=4))' < /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.raw.json > /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.formatted.json
+ /usr/bin/python3 -c 'import json, sys; print(json.dumps(json.load(sys.stdin), indent=4))'
RUN: at line 3: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/FileCheck --input-file=/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.formatted.json --check-prefix=CHECK /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/clang/test/Analysis/ftime-trace.cpp
+ /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/bin/FileCheck --input-file=/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.formatted.json --check-prefix=CHECK /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/clang/test/Analysis/ftime-trace.cpp
/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/clang/test/Analysis/ftime-trace.cpp:34:11: error: CHECK: expected string not found in input
// CHECK: "name": "Total CheckerManager::runCheckersForStmt (Pre)",
          ^
/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.formatted.json:2474:3: note: scanning from here
 }
  ^
/home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.formatted.json:2638:2: note: possible intended match here
 "name": "Total CheckerManager::runCheckersForStmt (Post)",
 ^

Input file: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm_build_msan/tools/clang/test/Analysis/Output/ftime-trace.cpp.tmp.formatted.json
Check file: /home/b/sanitizer-aarch64-linux-bootstrap-msan/build/llvm-project/clang/test/Analysis/ftime-trace.cpp

-dump-input=help explains the following input dump.

Input was:
<<<<<<
            .
            .
            .
         2469:  "dur": 1595, 
         2470:  "name": "Total dispatchWorkItem PostStmt", 
         2471:  "args": { 
         2472:  "count": 31, 
         2473:  "avg ms": 0 
         2474:  } 
check:34'0       X error: no match found

@Steelskin Steelskin deleted the fabrice/msvc-paths-consider-sdk-version branch March 12, 2025 17:11
Steelskin added a commit to Steelskin/llvm-project that referenced this pull request Mar 12, 2025
Currently, the `-Xmicrosoft-windows-sdk-version` is only used if
`-Xmicrosoft-windows-sdk-root` is also provided. This is a surprising
behavior since the argument should still be taking effect if LLVM uses
the Windows SDK root from the registry.

Tested locally in a simple Hello World program including `Windows.h` and
compiled with `-Xmicrosoft-windows-sdk-version 10.0.18362.0` on a system
where the SDK 10.0.22621.0 is also installed and verified that the
correct header was included.

Co-authored-by: Saleem Abdulrasool <[email protected]>
(cherrry picked from commit
[606e9fa](swiftlang@606e9fa)
compnerd added a commit to swiftlang/llvm-project that referenced this pull request Mar 13, 2025
…version

🍒 [WindowsDriver] Always consider `WinSdkVersion` (llvm#130377)
Steelskin added a commit to Steelskin/llvm-project that referenced this pull request Mar 19, 2025
Cherry-picked from llvm#10240

Currently, the `-Xmicrosoft-windows-sdk-version` is only used if
`-Xmicrosoft-windows-sdk-root` is also provided. This is a surprising
behavior since the argument should still be taking effect if LLVM uses
the Windows SDK root from the registry.

Tested locally in a simple Hello World program including `Windows.h` and
compiled with `-Xmicrosoft-windows-sdk-version 10.0.18362.0` on a system
where the SDK 10.0.22621.0 is also installed and verified that the
correct header was included.

Co-authored-by: Saleem Abdulrasool <[email protected]>
(cherrry picked from commit
[606e9fa](swiftlang@606e9fa)
shahmishal added a commit to swiftlang/llvm-project that referenced this pull request Mar 25, 2025
🍒 [WindowsDriver] Always consider `WinSdkVersion` (llvm#130377)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' platform:windows
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants