-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Convert built-in targets to JSON #34980
Conversation
r? @nrc (rust_highfive has picked a reviewer for you, use r? to override) |
CC @alexcrichton since we've talked about this a few times. |
I can delete commits or squash things together but @jcreekmore and I wanted to provide all the pieces along the way for the review process. |
|
||
("le32-unknown-nacl", le32_unknown_nacl), | ||
("asmjs-unknown-emscripten", asmjs_unknown_emscripten) | ||
("x86_64-unknown-linux-gnu", "json/x86_64-unknown-linux-gnu.json"), |
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.
Now that these are just strings and all have the same name, you may be able to change the include to:
include_str!(concat!("json/", $target, ".json"))
And that way each target only needs to be listed here once
Yeah, losing the comments seems pretty bad, but switching to TOML kinda defeats the motivation of making sure the JSON parser works. Unless they share sufficient code to give us confidence in both. If that's the case then I'm fine doing them in TOML, as long as TOML target specs aren't exposed publicly. Another approach here that is quite simple might be to just roundtrip every built-in target spec through JSON before using it. |
That makes sense and should be fairly straightforward to do.
|
@alexcrichton That works. We'll get that rebased in. |
I wanted to write up an RFC on this. I feel like this PR as it is currently is lacking somewhat. Most notably:
IMO the thing to do here is to deprecate JSON target specs in favour of whatever better format over a long period of time. |
8c54a6a
to
e1e95a4
Compare
@alexcrichton and @brson, I rebased the branch so that it adds unit tests for encoding and decoding all of the builtin targets as well as pushing the builtin targets through the JSON codec at runtime. Is this closer to what you wanted? |
Huh. Looks like the tests failed on travis because of a lack of ios simulator when I am trying to instantiate the Target for checking the encoding. Thoughts?
|
Oh that's actually because they just can't be loaded anywhere but somewhere with the |
@alexcrichton One idea to fix it would be to change all the I've roughly done this in cardoe@d16b7d0 if that sounds reasonable we can rebase that into this branch or clean it up and make it its own PR. |
@cardoe sounds reasonable to me! |
e1e95a4
to
436c467
Compare
☔ The latest upstream changes (presumably #33363) made this pull request unmergeable. Please resolve the merge conflicts. |
Not all TargetOptions are exposed via the JSON interface to create different targets. This exposes all the missing items and reorders them to match the structure so that it is easier in the future to identify missing items. Signed-off-by: Doug Goldstein <[email protected]>
Target's can already be built up from JSON files as well as built into librustc_back so this adds the ability to convert any Target back into JSON. Signed-off-by: Doug Goldstein <[email protected]>
Change all the target generation functions to return a Result<Target, String> so that targets that are unable to be instantiated can be expressed as an Err instead of a panic!(). This should improve rust-lang#33497 as well.
Expand the supported_targets!() macro to also generate a set of JSON encode/decode tests to verify that the parser will encode and decode all of the fields needed for all of the builtin targets. Additionally, add PartialEq to Target and TargetOptions in support of the tests.
Since we can know which targets are instantiable on a particular host, it does not make sense to list invalid targets in the target print code. Filter the list of targets to only include the targets that can be instantiated.
436c467
to
54c61ff
Compare
@alexcrichton This should be good to go now. It should also resolve the issues that people reported in the referenced issues as well. |
Awesome, thanks @cardoe and @jcreekmore! |
Convert built-in targets to JSON Convert the built-in targets to JSON to ensure that the JSON parser is always fully featured. This follows on #32988 and #32847. The PR includes a number of extra commits that are just intermediate changes necessary for bisectibility and the ability to prove correctness of the change.
…henkov Defer Apple SDKROOT detection to link time. This defers the detection of the SDKROOT for Apple iOS/tvOS targets to link time, instead of when the `Target` is defined. This allows commands that don't need to link to work (like `rustdoc` or `rustc --print=target-list`). This also makes `--print=target-list` a bit faster. This also removes the note in the platform support documentation about these targets being missing. When I wrote it, I misunderstood how the SDKROOT stuff worked. Notes: * This means that JSON spec targets can't explicitly override these flags. I think that is probably fine, as I believe the value is generally required, and can be set with the SDKROOT environment variable. * This changes `x86_64-apple-tvos` to use `appletvsimulator`. I think the original code was wrong (it was using `iphonesimulator`). Also, `x86_64-apple-tvos` seems broken in general, and I cannot build it locally. The `data_layout` does not appear to be correct (it is a copy of the arm64 layout instead of the x86_64 layout). I have not tried building Apple's LLVM to see if that helps, but I suspect it is just wrong (I'm uncertain since I don't know how the tvOS simulator works with its bitcode-only requirements). * I'm tempted to remove the use of `Result` for built-in target definitions, since I don't think they should be fallible. This was added in rust-lang#34980, but that only relates to JSON definitions. I think the built-in targets shouldn't fail. I can do this now, or not. Fixes rust-lang#36156 Fixes rust-lang#76584
Convert the built-in targets to JSON to ensure that the JSON parser is always fully featured. This follows on #32988 and #32847. The PR includes a number of extra commits that are just intermediate changes necessary for bisectibility and the ability to prove correctness of the change.