tool: Add is_like_clang_cl() getter#1357
Conversation
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
left a comment
There was a problem hiding this comment.
Thanks!
could we have a public Tool::family() getter
Yes that'd makes sense with non_exhaustive enum
|
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 😂 |
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.
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.
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?