Allow setting `target_family` to multiple values, and implement `target_family="wasm"` by nagisa · Pull Request #84072 · rust-lang/rust

nagisa · 2021-04-10T20:33:52Z

As per the conclusion in this thread, this implements an ability to specify any number of target_family values, allowing for more flexible generic groups, or "families", to be created than just the OS-based unix/windows dichotomy.

cc rust-lang/reference#1006

rust-highfive · 2021-04-10T20:33:54Z

r? @petrochenkov

(rust-highfive has picked a reviewer for you, use r? to override)

nagisa · 2021-04-10T20:35:11Z

Note: this will want at least an FCP for T-lang here or on the reference issue before it is merged.

joshtriplett · 2021-04-10T20:58:22Z

@rfcbot merge

rfcbot · 2021-04-10T20:58:23Z

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

This enables us to set more generic labels shared between targets. For example `target_family="wasm"` across all targets that are conceptually "wasm". See rust-lang/reference#1006

nikomatsakis · 2021-04-13T18:00:48Z

I'd like to see a better write-up of what is happening here -- perhaps in the form of a PR to some documentation? I can't really understand the expected usage pattern yet.

nagisa · 2021-04-13T22:14:25Z

perhaps in the form of a PR to some documentation? I can't really understand the expected usage pattern yet.

I… honestly don't know what documentation I'd adjust – the only thing that comes to mind is the book, but adjusting learning materials for something that is only available in nightly seems tad too hasty. I'm also not the one championing for this change – just something I ended up implementing.

All that said, I can quickly (given its 1am here) give a brief overview of the motivations I'm aware of:

It is fairly common to write code that is conditional on the architecture, but does not care particularly much about the pointer width. Taking x86 as an example, this tends to present itself in the code as cfg(any(target_arch="x86", target_arch="x86_64")). With this proposed change to target_family we'd be able to add a "family" that encompasses both x86 and x86_64 architectures, reducing the amount of typing necessary down to cfg(target_family="x86").

wasm is a much better motivating example in this instance, or so I'm told, because wasm32 and wasm64 are only different in their support for indexing memory by 64-bit types (which is in contrast to, say, x86 and ARM which took the opportunity to improve on their instruction set in more involving ways) and so almost every piece of code out there that would be conditional on wasm support would have to write cfg(any(target_arch="wasm32", target_arch="wasm64")).

Now,, one might argue that it'd make more sense to instead replace target_arch="wasm32" with target_arch="wasm" in that case, much like we only have target_arch="arm" for the bouquet of 32-bit ARM targets, but the ship appears to have sailed on that one. Expanding the things target_family can mean is thus proposed as the backwards compatible solution.

nikomatsakis · 2021-04-14T15:00:14Z

@nagisa I'd be good with writing up a mini-RFC describing the change to the feature :)

nikomatsakis · 2021-04-14T15:01:02Z

So in short, we now have target_family as a built-in option, and we have some families defined...is there a table defining which target architectures map to which families?

rfcbot · 2021-04-14T19:08:40Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot · 2021-04-24T19:10:08Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

nagisa · 2021-04-24T19:17:49Z

@nikomatsakis this PR only adds target_family="wasm" and other potential groupings were left up to future additions. rust-lang/reference#1006 describes the state after this PR would land as well as the values that would be possible were this PR land.

petrochenkov · 2021-04-30T22:46:31Z

@bors r+

bors · 2021-04-30T22:46:32Z

📌 Commit dfe3c3c has been approved by petrochenkov

… r=petrochenkov Allow setting `target_family` to multiple values, and implement `target_family="wasm"` As per the conclusion in [this thread](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Are.20we.20comfortable.20with.20adding.20an.20insta-stable.20cfg.28wasm.29.3F/near/233158441), this implements an ability to specify any number of `target_family` values, allowing for more flexible generic groups, or "families", to be created than just the OS-based unix/windows dichotomy. cc rust-lang/reference#1006

bors · 2021-05-01T20:31:57Z

⌛ Testing commit dfe3c3c with merge 716ea2c85ff2d039b8f911cb650662ff6a0fbfe1...

bors · 2021-05-01T21:07:05Z

💔 Test failed - checks-actions

petrochenkov · 2021-05-01T21:52:52Z

Some rustdoc lints need fixing.

nagisa · 2021-05-02T21:34:04Z

@bors r=petrochenkov

bors · 2021-05-02T21:34:05Z

📌 Commit 1a491e2 has been approved by petrochenkov

Rollup of 6 pull requests Successful merges: - rust-lang#84072 (Allow setting `target_family` to multiple values, and implement `target_family="wasm"`) - rust-lang#84744 (Add ErrorKind::OutOfMemory) - rust-lang#84784 (Add help message to suggest const for unused type param) - rust-lang#84811 (RustDoc: Fix bounds linking trait.Foo instead of traitalias.Foo) - rust-lang#84818 (suggestion for unit enum variant when matched with a patern) - rust-lang#84832 (Do not print visibility in external traits) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

Pkgsrc changes: * Bump bootstrap requirements to 1.53.0. * Adjust patches, adapt to upstream changes, adjust cargo checksums * If using an external llvm, require >= 10.0 Upsteream changes: Version 1.54.0 (2021-07-29) ============================ Language ----------------------- - [You can now use macros for values in built-in attribute macros.][83366] While a seemingly minor addition on its own, this enables a lot of powerful functionality when combined correctly. Most notably you can now include external documentation in your crate by writing the following. ```rust #![doc = include_str!("README.md")] ``` You can also use this to include auto-generated modules: ```rust #[path = concat!(env!("OUT_DIR"), "/generated.rs")] mod generated; ``` - [You can now cast between unsized slice types (and types which contain unsized slices) in `const fn`.][85078] - [You can now use multiple generic lifetimes with `impl Trait` where the lifetimes don't explicitly outlive another.][84701] In code this means that you can now have `impl Trait<'a, 'b>` where as before you could only have `impl Trait<'a, 'b> where 'b: 'a`. Compiler ----------------------- - [Rustc will now search for custom JSON targets in `/lib/rustlib/<target-triple>/target.json` where `/` is the "sysroot" directory.][83800] You can find your sysroot directory by running `rustc --print sysroot`. - [Added `wasm` as a `target_family` for WebAssembly platforms.][84072] - [You can now use `#[target_feature]` on safe functions when targeting WebAssembly platforms.][84988] - [Improved debugger output for enums on Windows MSVC platforms.][85292] - [Added tier 3\* support for `bpfel-unknown-none` and `bpfeb-unknown-none`.][79608] \* Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries ----------------------- - [`panic::panic_any` will now `#[track_caller]`.][85745] - [Added `OutOfMemory` as a variant of `io::ErrorKind`.][84744] - [ `proc_macro::Literal` now implements `FromStr`.][84717] - [The implementations of vendor intrinsics in core::arch have been significantly refactored.][83278] The main user-visible changes are a 50% reduction in the size of libcore.rlib and stricter validation of constant operands passed to intrinsics. The latter is technically a breaking change, but allows Rust to more closely match the C vendor intrinsics API. Stabilized APIs --------------- - [`BTreeMap::into_keys`] - [`BTreeMap::into_values`] - [`HashMap::into_keys`] - [`HashMap::into_values`] - [`arch::wasm32`] - [`VecDeque::binary_search`] - [`VecDeque::binary_search_by`] - [`VecDeque::binary_search_by_key`] - [`VecDeque::partition_point`] Cargo ----- - [Added the `--prune <spec>` option to `cargo-tree` to remove a package from the dependency graph.][cargo/9520] - [Added the `--depth` option to `cargo-tree` to print only to a certain depth in the tree ][cargo/9499] - [Added the `no-proc-macro` value to `cargo-tree --edges` to hide procedural macro dependencies.][cargo/9488] - [A new environment variable named `CARGO_TARGET_TMPDIR` is available.][cargo/9375] This variable points to a directory that integration tests and benches can use as a "scratchpad" for testing filesystem operations. Compatibility Notes ------------------- - [Mixing Option and Result via `?` is no longer permitted in closures for inferred types.][86831] - [Previously unsound code is no longer permitted where different constructors in branches could require different lifetimes.][85574] - As previously mentioned the [`std::arch` instrinsics now uses stricter const checking][83278] than before and may reject some previously accepted code. - [`i128` multiplication on Cortex M0+ platforms currently unconditionally causes overflow when compiled with `codegen-units = 1`.][86063] [85574]: rust-lang/rust#85574 [86831]: rust-lang/rust#86831 [86063]: rust-lang/rust#86063 [86831]: rust-lang/rust#86831 [79608]: rust-lang/rust#79608 [84988]: rust-lang/rust#84988 [84701]: rust-lang/rust#84701 [84072]: rust-lang/rust#84072 [85745]: rust-lang/rust#85745 [84744]: rust-lang/rust#84744 [85078]: rust-lang/rust#85078 [84717]: rust-lang/rust#84717 [83800]: rust-lang/rust#83800 [83366]: rust-lang/rust#83366 [83278]: rust-lang/rust#83278 [85292]: rust-lang/rust#85292 [cargo/9520]: rust-lang/cargo#9520 [cargo/9499]: rust-lang/cargo#9499 [cargo/9488]: rust-lang/cargo#9488 [cargo/9375]: rust-lang/cargo#9375 [`BTreeMap::into_keys`]: https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.into_keys [`BTreeMap::into_values`]: https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.into_values [`HashMap::into_keys`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.into_keys [`HashMap::into_values`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.into_values [`arch::wasm32`]: https://doc.rust-lang.org/core/arch/wasm32/index.html [`VecDeque::binary_search`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search [`VecDeque::binary_search_by`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search_by [`VecDeque::binary_search_by_key`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search_by_key [`VecDeque::partition_point`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.partition_point

target_family support was only added May 2, after the nightly we're using (rust-lang/rust#84072).

nagisa added the T-lang Relevant to the language team label Apr 10, 2021

rust-highfive assigned petrochenkov Apr 10, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 10, 2021

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Apr 10, 2021

petrochenkov reviewed Apr 10, 2021
View reviewed changes

Comment threadcompiler/rustc_target/src/spec/mod.rs Outdated

petrochenkov added S-waiting-on-team and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 10, 2021

Allow setting target_family to multiple values
4afea69
This enables us to set more generic labels shared between targets. For example `target_family="wasm"` across all targets that are conceptually "wasm". See rust-lang/reference#1006

nagisa force-pushed the target-family-two-the-movie branch from 5aca958 to dfe3c3cCompare April 10, 2021 22:18

rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Apr 14, 2021

rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Apr 14, 2021

rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Apr 24, 2021

rfcbot added the to-announce Announce this issue on triage meeting label Apr 24, 2021

apiraino removed the to-announce Announce this issue on triage meeting label Apr 29, 2021

petrochenkov added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-team labels Apr 30, 2021

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 30, 2021

Dylan-DPC-zz mentioned this pull request May 1, 2021
Rollup of 6 pull requests #84788
Closed

Dylan-DPC-zz mentioned this pull request May 1, 2021
Rollup of 6 pull requests #84791
Closed

This comment has been minimized.
Sign in to view

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 1, 2021

petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 1, 2021

Set target_family="wasm" for wasm targets
1a491e2

nagisa force-pushed the target-family-two-the-movie branch from dfe3c3c to 1a491e2Compare May 2, 2021 21:33

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 2, 2021

Dylan-DPC-zz mentioned this pull request May 2, 2021
Rollup of 6 pull requests #84840
Merged

bors merged commit 966e9e2 into rust-lang:masterMay 3, 2021

rustbot added this to the 1.54.0 milestone May 3, 2021

abrgr added a commit to ratchetdesigns/ts-bindgen that referenced this pull request Dec 27, 2021
feat: add rustfmt dep and get builds working on nightly
a407511
target_family support was only added May 2, after the nightly we're using (rust-lang/rust#84072).

taiki-e mentioned this pull request Jul 26, 2022
chore: use target_family wasm instead of wasm32 tokio-rs/tokio#4864
Merged

Uh oh!

Uh oh!

Conversation

nagisa commented Apr 10, 2021

Uh oh!

rust-highfive commented Apr 10, 2021

Uh oh!

nagisa commented Apr 10, 2021

Uh oh!

joshtriplett commented Apr 10, 2021

Uh oh!

rfcbot commented Apr 10, 2021• edited by cramertj Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

nikomatsakis commented Apr 13, 2021

Uh oh!

nagisa commented Apr 13, 2021

Uh oh!

nikomatsakis commented Apr 14, 2021

Uh oh!

nikomatsakis commented Apr 14, 2021

Uh oh!

rfcbot commented Apr 14, 2021

Uh oh!

rfcbot commented Apr 24, 2021

Uh oh!

nagisa commented Apr 24, 2021

Uh oh!

petrochenkov commented Apr 30, 2021

Uh oh!

bors commented Apr 30, 2021

Uh oh!

bors commented May 1, 2021

Uh oh!

This comment has been minimized.

bors commented May 1, 2021

Uh oh!

petrochenkov commented May 1, 2021

Uh oh!

nagisa commented May 2, 2021

Uh oh!

bors commented May 2, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

rfcbot commented Apr 10, 2021•
edited by cramertj
Loading