tool: Add is_like_clang_cl() getter
#1357
Merged
Conversation
This file contains 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
In `ring` we need to check if the compiler is `clang-cl` to prevent overwriting it with `clang` (see all details in briansmith/ring#2215), but `cc-rs` does not currently expose this despite already tracking it. By adding this getter we can steer that logic to not overwrite the compiler when it is `clang-cl`. Perhaps, since `ToolFamily` is `pub` (but not yet reexported from `lib.rs`), could we have a public `Tool::family()` getter to not have to extend these `is_xxx()` getters whenever a downstream crate wants to know something new?
NobodyXu
approved these changes
Jan 10, 2025
|
cc usually has a new release every Friday (and we already have one today). If this is very important, then I can cut another release today/tomorrow |
Let's see if I can make a second PR.
Unsure, let's see how quickly |
It looks like it failed: #1355 Meaning you could perhaps trivially roll this in :) |
|
Thanks, I forgot to check my release PR 😂 |
MarijnS95
added a commit
to MarijnS95/cc-rs
that referenced
this pull request
Jan 10, 2025
Instead of adding a new `is_like_xxx()` function every time new information is needed, or new enumeration variants would be added, provide the (now `non_exhaustive`) `enum` directly to callers to match what they're interested in. Deprecate the existing functions to point users to the new pattern. Also removes `is_like_clang_cl()` again from rust-lang#1357 since that did not yet make it into a release, and would only cause unnecessary duplication in our API patterns.
MarijnS95
added a commit
to MarijnS95/cc-rs
that referenced
this pull request
Jan 10, 2025
Instead of adding a new `is_like_xxx()` function every time new information is needed, or new enumeration variants would be added, provide the (now `non_exhaustive`) `enum` directly to callers to match what they're interested in. Also removes `is_like_clang_cl()` again from rust-lang#1357 since that did not yet make it into a release, and would only cause unnecessary duplication in our API patterns.
Merged
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.
In
ringwe need to check if the compiler isclang-clto prevent overwriting it withclang(see all details in briansmith/ring#2215), butcc-rsdoes not currently expose this despite already tracking it. By adding this getter we can steer that logic to not overwrite the compiler when it isclang-cl.Perhaps, since
ToolFamilyispub(but not yet reexported fromlib.rs), could we have a publicTool::family()getter to not have to extend theseis_xxx()getters whenever a downstream crate wants to know something new?