rustc: Add target_vendor for target triples #28612
Conversation
This adds a new target property, `target_vendor` which can be used as a matcher for conditional compilation. The vendor is part of the autoconf target triple: <arch><sub>-<vendor>-<os>-<env> The default value for `target_vendor` is "unknown". Matching against the `target_vendor` with `#[cfg]` is currently feature gated as `cfg_target_vendor`.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
| @@ -18,6 +18,7 @@ pub fn target() -> Target { | |||
| arch: "aarch64".to_string(), | |||
| target_os: "android".to_string(), | |||
| target_env: "".to_string(), | |||
| target_vendor: "linux".to_string(), | |||
There was a problem hiding this comment.
I'm sure what the correct value is. "linux" is part of the triple, however it is not an official vendor name in this list: http://llvm.org/docs/doxygen/html/classllvm_1_1Triple.html#a96fe35195867c94aef1adf2ad0e20eec
There was a problem hiding this comment.
It looks like LLVM normalize arm-linux-androideabi to arm--linux-androideabi which in theory means that target_os should be "linux" and target_env should be "androideabi", but we can't really change that now! Regardless though it looks like "unknown" is the right vendor for the android triples.
There was a problem hiding this comment.
Thanks for looking it up! I changed it to "unknown".
This adds a new target property, `target_vendor`. It is to be be used as a matcher for conditional compilation. The vendor is part of the [autoconf target triple](http://llvm.org/docs/doxygen/html/classllvm_1_1Triple.html#details): `<arch><sub>-<vendor>-<os>-<env>`. `arch`, `target_os` and `target_env` are already supported by Rust. This change was suggested in PR #28593. It enables conditional compilation based on the vendor. This is needed for the rumprun target, which needs to match against both, target_os and target_vendor. The default value for `target_vendor` is "unknown", "apple" and "pc" are other common values. Matching against the `target_vendor` is introduced behind the feature gate `#![feature(cfg_target_vendor)]`. This is the first time I messed around with rustc internals. I just added the my code where I found the existing `target_*` variables, hopefully I haven't missed anything. Please review with care. :) r? @alexcrichton
…dor, r=joshtriplett,Centril Stabilize cfg_target_vendor This stabilizes the use of `cfg(target_vendor = "...")` and removes the corresponding `cfg_target_vendor` feature. Other unstable cfgs remain behind their existing feature gates. This functionality was added back in 2015 in rust-lang#28612 to complete the coverage of target tuples (`<arch><sub>-<vendor>-<os>-<env>`). [RFC 131](https://github.com/rust-lang/rfcs/blob/master/text/0131-target-specification.md) governs the target specification, not including `target_vendor` seems to have just been an oversight. `target_os`, `target_family`, and `target_arch` are stable as of 1.0.0. `target_env` was also not mentioned in RFC 131, was added in rust-lang#24777, never behind a feature_gate, and insta-stable at 1.1.0. The functionality is tested in [test/run-pass/cfg/cfg-target-vendor.rs](https://github.com/rust-lang/rust/blob/master/src/test/run-pass/cfg/cfg-target-vendor.rs). Closes rust-lang#29718
…dor, r=joshtriplett,Centril Stabilize cfg_target_vendor This stabilizes the use of `cfg(target_vendor = "...")` and removes the corresponding `cfg_target_vendor` feature. Other unstable cfgs remain behind their existing feature gates. This functionality was added back in 2015 in rust-lang#28612 to complete the coverage of target tuples (`<arch><sub>-<vendor>-<os>-<env>`). [RFC 131](https://github.com/rust-lang/rfcs/blob/master/text/0131-target-specification.md) governs the target specification, not including `target_vendor` seems to have just been an oversight. `target_os`, `target_family`, and `target_arch` are stable as of 1.0.0. `target_env` was also not mentioned in RFC 131, was added in rust-lang#24777, never behind a feature_gate, and insta-stable at 1.1.0. The functionality is tested in [test/run-pass/cfg/cfg-target-vendor.rs](https://github.com/rust-lang/rust/blob/master/src/test/run-pass/cfg/cfg-target-vendor.rs). Closes rust-lang#29718
This adds a new target property,
target_vendor. It is to be be used as a matcher for conditional compilation. The vendor is part of the autoconf target triple:<arch><sub>-<vendor>-<os>-<env>.arch,target_osandtarget_envare already supported by Rust.This change was suggested in PR #28593. It enables conditional compilation based on the vendor. This is needed for the rumprun target, which needs to match against both, target_os and target_vendor.
The default value for
target_vendoris "unknown", "apple" and "pc" are other common values.Matching against the
target_vendoris introduced behind the feature gate#![feature(cfg_target_vendor)].This is the first time I messed around with rustc internals. I just added the my code where I found the existing
target_*variables, hopefully I haven't missed anything. Please review with care. :)r? @alexcrichton