rustdoc fails when building rust 1.85.0 for ARM targets #137366
Comments
rustbot
added
the
needs-triage
|
Thanks for the report! I'm able to reproduce this (on latest master, too). What I'm thinking is that here it is collecting a map of all features. However, ARM and AARCH64 both enable features of the same name, but with different Stability settings. Thus there are key collisions in the map. cc @RalfJung since it looks like you've been doing some work here. (Presumably this is from #133417) |
ehuss
added
the
regression-from-stable-to-stable
rustbot
added
the
I-prioritize
|
Hm... @ehuss yeah I think you found the culprit, for rustdoc we're merging all features into one map and that just doesn't make sense, features of the same name on different targets will overwrite each other and we'll get some "random" final idea of what is and is not stable. It's kind of surprising that this worked for so long. Cc @workingjubilee @rust-lang/rustdoc |
|
The immediate short-term fix I can think of is to do that merging in a more clever way, where the "more stable" feature takes precedent. But really I feel this needs to be redesigned, it's just not coherent to say "use all features from all targets". We probably want to only enable them all for |
jieyouxu
added
the
T-rustdoc
|
FWIW there is a potential stability hazard here: rustdoc will (have to) accept code with |
|
#137632 should fix the issue (but not the stability hazard). |
Is there any reason we can't emit docs for |
|
I don't understand the question / comment, sorry. Too many negations.^^ This is about I don't even know what exactly rustdoc currently does for |
|
Rustdoc itself treats rust/src/librustdoc/clean/types.rs Lines 1071 to 1086 in 2af87ea However, while I can use nonexistent target features in cfg, I can't use nonexistent enable flags. $ cat lib.rs
#[target_feature(enable="blablabla")]
pub fn add(left: u64, right: u64) -> u64 {
left + right
}
#[cfg(target_feature="blablabla")]
pub fn sub(left: u64, right: u64) -> u64 {
left - right
}
$ rustdoc lib.rs
error: the feature named `blablabla` is not valid for this target
--> lib.rs:1:18
|
1 | #[target_feature(enable="blablabla")]
| ^^^^^^^^^^^^^^^^^^ `blablabla` is not valid for this target
error: aborting due to 1 previous errorI'm surprised that this doesn't successfully generate docs. Rustdoc doesn't generate code, so why does it care about codegen parameters other than displaying them? With
The answer to this question has to be "yes." There's a bunch of other stuff that rustdoc accepts that rustc rejects and that we can't really make any promises about. |
I don't know what that means. What I was asking is, if I have
Rustdoc also fails when the program is not valid Rust syntax, or ill-typed, or uses Target features are not codegen parameters, they are a concept of Rust proper. Target features map to codegen parameters, but well, everything Rust does eventually maps to some aspect of codegen so that doesn't mean anything. |
Got it. |
…r=workingjubilee rustdoc: when merging target features, keep the highest stability This addresses rust-lang#137366. (Not closing since we might consider a backport.) rustdoc wants to pretend that it runs for all targets at once and has all target features, so `tcx.rust_target_features()` will actually be all the target features. For target features that exist on multiple targets, the stability info for one of the targets will be picked (first or last in the list, I guess). All the code consuming that query has to be aware that the data is basically nonsense when running in rustdoc, but the logic checking for unstable or forbidden `#[target_feature]` attributes was not aware of that. This PR makes the `tcx.rust_target_features()` info in rustdoc slightly less nonsensical (and decidedly less random) by having the "most stable" target feature take precedent. That deals with rust-lang#137366 (a conflict between a stable and a "forbidden" target feature of the same name for different targets), and also deals with the situation (that we did not seem to have yet) of a conflict between a stable and an unstable target feature of the same name. Note that if there are two unstable target features of the same name, rustdoc might still require the "wrong" nightly feature to be enabled -- but this can only possibly affect unstable code so I guess we can wait until that actually happens, and then someone will have to rewrite this entire thing to be less hacky.
…r=workingjubilee rustdoc: when merging target features, keep the highest stability This addresses rust-lang#137366. (Not closing since we might consider a backport.) rustdoc wants to pretend that it runs for all targets at once and has all target features, so `tcx.rust_target_features()` will actually be all the target features. For target features that exist on multiple targets, the stability info for one of the targets will be picked (first or last in the list, I guess). All the code consuming that query has to be aware that the data is basically nonsense when running in rustdoc, but the logic checking for unstable or forbidden `#[target_feature]` attributes was not aware of that. This PR makes the `tcx.rust_target_features()` info in rustdoc slightly less nonsensical (and decidedly less random) by having the "most stable" target feature take precedent. That deals with rust-lang#137366 (a conflict between a stable and a "forbidden" target feature of the same name for different targets), and also deals with the situation (that we did not seem to have yet) of a conflict between a stable and an unstable target feature of the same name. Note that if there are two unstable target features of the same name, rustdoc might still require the "wrong" nightly feature to be enabled -- but this can only possibly affect unstable code so I guess we can wait until that actually happens, and then someone will have to rewrite this entire thing to be less hacky.
…r=workingjubilee rustdoc: when merging target features, keep the highest stability This addresses rust-lang#137366. (Not closing since we might consider a backport.) rustdoc wants to pretend that it runs for all targets at once and has all target features, so `tcx.rust_target_features()` will actually be all the target features. For target features that exist on multiple targets, the stability info for one of the targets will be picked (first or last in the list, I guess). All the code consuming that query has to be aware that the data is basically nonsense when running in rustdoc, but the logic checking for unstable or forbidden `#[target_feature]` attributes was not aware of that. This PR makes the `tcx.rust_target_features()` info in rustdoc slightly less nonsensical (and decidedly less random) by having the "most stable" target feature take precedent. That deals with rust-lang#137366 (a conflict between a stable and a "forbidden" target feature of the same name for different targets), and also deals with the situation (that we did not seem to have yet) of a conflict between a stable and an unstable target feature of the same name. Note that if there are two unstable target features of the same name, rustdoc might still require the "wrong" nightly feature to be enabled -- but this can only possibly affect unstable code so I guess we can wait until that actually happens, and then someone will have to rewrite this entire thing to be less hacky.
…r=workingjubilee rustdoc: when merging target features, keep the highest stability This addresses rust-lang#137366. (Not closing since we might consider a backport.) rustdoc wants to pretend that it runs for all targets at once and has all target features, so `tcx.rust_target_features()` will actually be all the target features. For target features that exist on multiple targets, the stability info for one of the targets will be picked (first or last in the list, I guess). All the code consuming that query has to be aware that the data is basically nonsense when running in rustdoc, but the logic checking for unstable or forbidden `#[target_feature]` attributes was not aware of that. This PR makes the `tcx.rust_target_features()` info in rustdoc slightly less nonsensical (and decidedly less random) by having the "most stable" target feature take precedent. That deals with rust-lang#137366 (a conflict between a stable and a "forbidden" target feature of the same name for different targets), and also deals with the situation (that we did not seem to have yet) of a conflict between a stable and an unstable target feature of the same name. Note that if there are two unstable target features of the same name, rustdoc might still require the "wrong" nightly feature to be enabled -- but this can only possibly affect unstable code so I guess we can wait until that actually happens, and then someone will have to rewrite this entire thing to be less hacky.
Rollup merge of rust-lang#137632 - RalfJung:rustdoc-target-features, r=workingjubilee rustdoc: when merging target features, keep the highest stability This addresses rust-lang#137366. (Not closing since we might consider a backport.) rustdoc wants to pretend that it runs for all targets at once and has all target features, so `tcx.rust_target_features()` will actually be all the target features. For target features that exist on multiple targets, the stability info for one of the targets will be picked (first or last in the list, I guess). All the code consuming that query has to be aware that the data is basically nonsense when running in rustdoc, but the logic checking for unstable or forbidden `#[target_feature]` attributes was not aware of that. This PR makes the `tcx.rust_target_features()` info in rustdoc slightly less nonsensical (and decidedly less random) by having the "most stable" target feature take precedent. That deals with rust-lang#137366 (a conflict between a stable and a "forbidden" target feature of the same name for different targets), and also deals with the situation (that we did not seem to have yet) of a conflict between a stable and an unstable target feature of the same name. Note that if there are two unstable target features of the same name, rustdoc might still require the "wrong" nightly feature to be enabled -- but this can only possibly affect unstable code so I guess we can wait until that actually happens, and then someone will have to rewrite this entire thing to be less hacky.
|
There's still no 1.85 version for termux because of this. Is there a rough estimate of when this will be fixed? |
|
AFAIK, it is fixed, and is nominated for backport to 1.86. |
|
@jpalus @extended-euclidean @truboxl would be great if you could test whether the latest nightly fixes this. This seems to affect fairly few people, so I am not sure if there will be a 1.85.1 release due to this, but yeah 1.86 should hopefully contain the fix. |
|
So I made an attempt at building nightly and I think things are looking good, better? I guess? :) On the bright side I see dist created doc artifacts:
Downside being build failed due to unresolved symbols when linking The static library I think these should be defined, no idea how it ends up like this. Maybe I messed something. |
|
Yeah no idea what's going on with those linker errors, but let's not discuss that on this issue. :) |
rustbot
added
P-high
Thanks! I can confirm latest nightly is building for the 2 targets I listed. |
jieyouxu
removed
the
needs-triage
Running
./x.py distresults in error on ARM 32-bit targets, works fine for aarch64 though:arm-unknown-linux-gnueabihf:armv7-unknown-linux-gnueabihf:Build is performed on
aarch64host although I think it shouldn't really matter.The text was updated successfully, but these errors were encountered: