Tracking Issue for changing rustc target docs #120745
Assignees
Labels
A-docs
Area: documentation for any part of the project, including the compiler, standard library, and tools
A-targets
Area: Concerning the implications of different compiler targets
C-tracking-issue
Category: A tracking issue for an RFC or an unstable feature.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
Noratrieb
added
C-tracking-issue
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this issue
Mar 24, 2024
…onur-ozkan Introduce infrastructure for generating target docs See rust-lang#120745 It's highly unlikely that the format is optimal, but it's okay at least and can always be improved. Mostly posting this to get something working so we can continue. Use `TARGET_CHECK_ONLY=0` to actually build the book instead of just checking the new docs. r? `@davidtwco`
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Mar 24, 2024
…onur-ozkan Introduce infrastructure for generating target docs See rust-lang#120745 It's highly unlikely that the format is optimal, but it's okay at least and can always be improved. Mostly posting this to get something working so we can continue. Use `TARGET_CHECK_ONLY=0` to actually build the book instead of just checking the new docs. r? ``@davidtwco``
This was referenced Apr 20, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jul 15, 2024
…tadata, r=Nilstrieb Fill out target-spec metadata for all targets **What does this PR try to resolve?** This PR completes the target-spec metadata fields for all targets. This is required for a corresponding Cargo PR which adds a check for whether a target supports building the standard library when the `-Zbuild-std=std` flag is passed ([see this issue](rust-lang/wg-cargo-std-aware#87). This functionality in Cargo is reliant on the output of `--print=target-spec-json`. **How should we test and review this PR?** Check that a given target-spec metadata has been updated with: ``` $ ./x.py build library/std $ build/host/stage1/bin/rustc --print=target-spec-json --target <target_name> -Zunstable-options ``` **Additional Information** A few things to note: * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build * There's no rush for this to be merged. I understand that the format for this is not finalised yet. * Related: rust-lang#120745
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this issue
Jul 15, 2024
…metadata, r=Nilstrieb Fill out target-spec metadata for all targets **What does this PR try to resolve?** This PR completes the target-spec metadata fields for all targets. This is required for a corresponding Cargo PR which adds a check for whether a target supports building the standard library when the `-Zbuild-std=std` flag is passed ([see this issue](rust-lang/wg-cargo-std-aware#87). This functionality in Cargo is reliant on the output of `--print=target-spec-json`. **How should we test and review this PR?** Check that a given target-spec metadata has been updated with: ``` $ ./x.py build library/std $ build/host/stage1/bin/rustc --print=target-spec-json --target <target_name> -Zunstable-options ``` **Additional Information** A few things to note: * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build * There's no rush for this to be merged. I understand that the format for this is not finalised yet. * Related: rust-lang#120745
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jul 15, 2024
…tadata, r=Nilstrieb Fill out target-spec metadata for all targets **What does this PR try to resolve?** This PR completes the target-spec metadata fields for all targets. This is required for a corresponding Cargo PR which adds a check for whether a target supports building the standard library when the `-Zbuild-std=std` flag is passed ([see this issue](rust-lang/wg-cargo-std-aware#87). This functionality in Cargo is reliant on the output of `--print=target-spec-json`. **How should we test and review this PR?** Check that a given target-spec metadata has been updated with: ``` $ ./x.py build library/std $ build/host/stage1/bin/rustc --print=target-spec-json --target <target_name> -Zunstable-options ``` **Additional Information** A few things to note: * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build * There's no rush for this to be merged. I understand that the format for this is not finalised yet. * Related: rust-lang#120745
|
status here: as can be seen, I haven't worked on this for a while. while I do intent to get back to it eventually, I don't want to block anyone else from doing things in this space. If someone is interested in picking this up, feel free to do so. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is the tracking issue for changing rustc target docs to be generated based on the existing target triple patterns, ensuring that there's a doc page for every single target.
Discussion in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/generating.20target.20documentation with a draft implementation in https://github.com/Nilstrieb/target-tier-docs-experiment.
Steps
descriptionfield to target definitions #121905Future possibilities
The text was updated successfully, but these errors were encountered: