Stop manually downloading hardcoded version of llvm/clang. #1478
Conversation
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
… included in Visual Studio
manodasanW
approved these changes
Mar 1, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Just use the one included in Visual Studio
CI runs have broken again because the hard-coded version of clang we manually download is now older than the version included in Visual Studio.
Given that the rationale at the time was apparently to test with a newer version than what was in VS, this strategy is now backfiring, as we are now testing with something older thatn what is in VS. Let's just use the inbox version going forward.
I'm fine with leaving that action yml around for now in case we change our minds, but we'll no longer call it.
Also of note: I found that somehow between the old clang and the new clang 19 that's included in VS, overriding ExecutablePath was causing clang-cl problems. I got as far as figuring out that with those overrides, the clang copy of
vadefs.hstopped including MSVC's copy ofvadefs.h, which left a bunch of types undefined, likeuintptr_t. The different line waswhich must have been interacting with some special magic that bakes in certain include paths depending on which binary is invoked. Whatever, I don't know. It's fixed now.