Expose target options via JSON

[cardoe]

A number of target options are not exposed via JSON. This updates the code to keep it in sync and re-orders the list to match the default implementation to hopefully make it easier for people to inspect to make sure items are not missing.

[cardoe]

The 2nd commit is optional. I can squash it in or delete it. I'd love to know if there's a way to programmatically enforce that all these options are exposed. This is also related to #32847, #32823, and #32818.

[cardoe]

r? @alexcrichton

Since @rust-highfive shunned this PR and @alexcrichton has reviewed my other PRs in this area.

[alexcrichton]

Thanks for the PR @cardoe! Like with #32847 the ideal solution here I think is to use a "one source of truth" tactic to ensure we don't forget new features in the future.

I'm gonna tag this with T-tools though so we discuss this during triage next week. We haven't discussed much about the stability story of target specs for now, and providing a guarantee that we expose everything is probably both desirable and needs to be considered carefully!

[bors]

☔ The latest upstream changes (presumably #32939) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

Ok, the tools team discussed this during triage the other day and the conclusion was that this seems good to do, but we really do want to use something like derive(RustcEncodable, RustcDecodable) instead of doing this by hand.

Could you make a structure which corresponds to the serialized version of a target specification and then have a conversion to the one that the compiler needs? (or just make them one and the same)

[cardoe]

@alexcrichton I'm just wondering if it would be acceptable to break compatibility of existing target JSON files and convert the internal structures to Encodable and Decodable? There's 3 fields with slightly different names (prefixed with target_) but then a whole slew of fields that are actually instead of a JSON options object instead of at the top level how they're currently parsed. The other approach would be to convert the internal structures to how the target JSON files are currently defined.

The reason I threw out the converting to the internal structure is that I think those are actually a bit cleaner since they encompass required fields vs optional fields nicely. Additionally Rust does have a history of breaking compatibility with the target JSON fields (it recently happened with the data_layout field) so it's not without precedent.

[cardoe]

I forgot to mention the obvious safe fallback is to implement a middle man structure that is Encodable and Decodable that follows the existing target JSON spec and converts to the internal structures as you originally mentioned but that seems like a lot of duplicated code.

[alexcrichton]

@cardoe one useful tactic I've taken in the past is to have an intermediate structure. This temporary structure matches the JSON spec, and then we provide conversions from the official struct to/from this temporary one. That should at least prevent breakage!

[alexcrichton]

Closing due to inactivity, but feel free to resubmit with a rebase!

[cardoe]

@alexcrichton I've finally had a chance to pick this up again. Unfortunately I think the intermediate struct idea and just putting #[derive(RustcDecodable, RustcEncodable)] on it won't work due to the target spec using fields that rustc-serialize cannot handle (e.g. "llvm-target"). As far as I'm aware serde is not yet allowed in the compiler so the path I'm taking now is to implement Encodable and Decodable by hand on struct Target. Then converting all the internal target specs to JSON and loading them with the include_str!() macro.

[alexcrichton]

@cardoe sounds good to me!