-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a description
field to target definitions
#121905
Conversation
These commits modify compiler targets. |
☔ The latest upstream changes (presumably #121903) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, r=me after rebase if you're happy
Are there other things we want to add here? Like which tier a target is, or a yes/no for host toolchain support or std support? These are things that are always specific to each target, so it avoids having to have a file just for this metadata in your other PR with the documentation. Though they do feel like a strange thing to have here, maybe together in a metadata
field.
This is the short description (`64-bit MinGW (Windows 7+)`) including the platform requirements. The reason for doing it like this is that this PR will be quite prone to conflicts whenever targets get added, so it should be as simple as possible to get it merged. Future PRs which migrate targets are scoped to groups of targets, so they will not conflict as they can just touch these. This moves some of the information from the rustc book into the compiler. It cannot be queried yet, that is future work. It is also future work to fill out all the descriptions, which will coincide with the work of moving over existing target docs to the new format.
5ac7607
to
1db67fb
Compare
@bors r=davidtwco |
@bors p=1 |
…idtwco Add a `description` field to target definitions Starts addressing rust-lang#121051 (review) This is the short description (`64-bit MinGW (Windows 7+)`) including the platform requirements. The reason for doing it like this is that this PR will be quite prone to conflicts whenever targets get added, so it should be as simple as possible to get it merged. Future PRs which migrate targets are scoped to groups of targets, so they will not conflict as they can just touch these. This moves some of the information from the rustc book into the compiler. It cannot be queried yet, that is future work. It is also future work to fill out all the descriptions, which will coincide with the work of moving over existing target docs to the new format. r? `@davidtwco` but anyone is also free to steal it
…idtwco Add a `description` field to target definitions Starts addressing rust-lang#121051 (review) This is the short description (`64-bit MinGW (Windows 7+)`) including the platform requirements. The reason for doing it like this is that this PR will be quite prone to conflicts whenever targets get added, so it should be as simple as possible to get it merged. Future PRs which migrate targets are scoped to groups of targets, so they will not conflict as they can just touch these. This moves some of the information from the rustc book into the compiler. It cannot be queried yet, that is future work. It is also future work to fill out all the descriptions, which will coincide with the work of moving over existing target docs to the new format. r? ``@davidtwco`` but anyone is also free to steal it
…idtwco Add a `description` field to target definitions Starts addressing rust-lang#121051 (review) This is the short description (`64-bit MinGW (Windows 7+)`) including the platform requirements. The reason for doing it like this is that this PR will be quite prone to conflicts whenever targets get added, so it should be as simple as possible to get it merged. Future PRs which migrate targets are scoped to groups of targets, so they will not conflict as they can just touch these. This moves some of the information from the rustc book into the compiler. It cannot be queried yet, that is future work. It is also future work to fill out all the descriptions, which will coincide with the work of moving over existing target docs to the new format. r? ```@davidtwco``` but anyone is also free to steal it
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#121065 (Add basic i18n guidance for `Display`) - rust-lang#121301 (errors: share `SilentEmitter` between rustc and rustfmt) - rust-lang#121744 (Stop using Bubble in coherence and instead emulate it with an intercrate check) - rust-lang#121829 (Dummy tweaks (attempt 2)) - rust-lang#121857 (Implement async closure signature deduction) - rust-lang#121894 (const_eval_select: make it safe but be careful with what we expose on stable for now) - rust-lang#121905 (Add a `description` field to target definitions) - rust-lang#122022 (loongarch: add frecipe and relax target feature) - rust-lang#122028 (Remove some dead code) r? `@ghost` `@rustbot` modify labels: rollup
☀️ Test successful - checks-actions |
Finished benchmarking commit (3c02972): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 644.518s -> 644.259s (-0.04%) |
FYI, |
lol, oops. Happy to take a PR adding it, or I will do it in the future |
Done: #122157 |
Add the new description field to Target::to_json, and add descriptions for some MSVC targets The original PR to add a `description` field to `Target` (<rust-lang#121905>) didn't add the field to `Target::to_json`, which meant that the `check_consistency` testwould fail if you tried to set a description as it wouldn't survive round-tripping via JSON: https://github.com/rust-lang/rust/actions/runs/8180997936/job/22370052535#step:27:4967 This change adds the field to `Target::to_json`, and sets some descriptions to verify that it works correctly.
Rollup merge of rust-lang#122157 - dpaoliello:targetdesc, r=Nilstrieb Add the new description field to Target::to_json, and add descriptions for some MSVC targets The original PR to add a `description` field to `Target` (<rust-lang#121905>) didn't add the field to `Target::to_json`, which meant that the `check_consistency` testwould fail if you tried to set a description as it wouldn't survive round-tripping via JSON: https://github.com/rust-lang/rust/actions/runs/8180997936/job/22370052535#step:27:4967 This change adds the field to `Target::to_json`, and sets some descriptions to verify that it works correctly.
Add the new description field to Target::to_json, and add descriptions for some MSVC targets The original PR to add a `description` field to `Target` (<rust-lang/rust#121905>) didn't add the field to `Target::to_json`, which meant that the `check_consistency` testwould fail if you tried to set a description as it wouldn't survive round-tripping via JSON: https://github.com/rust-lang/rust/actions/runs/8180997936/job/22370052535#step:27:4967 This change adds the field to `Target::to_json`, and sets some descriptions to verify that it works correctly.
Add metadata to targets follow up to rust-lang#121905 and rust-lang#122157 This adds four pieces of metadata to every target: - description - tier - host tools - std This information is currently scattered across target docs and both - not machine readable, making validation harder - sometimes subtly encoding by the table it's in, causing mistakes and making it harder to review changes to the properties By putting it in the compiler, we improve this. Later, we will use this canonical information to generate target documentation from it. I used find-replace for all the `description: None`. One thing I'm not sure about is the behavior for the JSON. It doesn't really make sense that custom targets supply this information, especially the tier. But for the roundtrip tests, we do need to print and parse it. Maybe emit a warning when a custom target provides the metadata key? Either way, I don't think that's important right now, this PR should get merged ASAP or it will conflict all over the place. r? davidtwco
Starts addressing #121051 (review)
This is the short description (
64-bit MinGW (Windows 7+)
) including the platform requirements.The reason for doing it like this is that this PR will be quite prone to conflicts whenever targets get added, so it should be as simple as possible to get it merged. Future PRs which migrate targets are scoped to groups of targets, so they will not conflict as they can just touch these.
This moves some of the information from the rustc book into the compiler.
It cannot be queried yet, that is future work. It is also future work to fill out all the descriptions, which will coincide with the work of moving over existing target docs to the new format.
r? @davidtwco but anyone is also free to steal it