Open
Description
I tried this code:
#![no_std]
pub fn xxx() {
f64::abs(1.0);
}
In Rust older than 1.84.
I expected to see this happen: successful compilation since f64::abs
is documented to be available since Rust 1.0.
Instead, this happened: compilation failure since f64::abs
in no std programs wasn't stabilized until Rust 1.84. This isn't documented anywhere and I had to go issue diving on GitHub.
@RalfJung said the keywords here are documenting path stability vs item stability.
Opening this issue to explore how to document the limited availability of items in no std programs.
In the absence of compiler infrastructure for this, free form text in the prose of the doc comment for the f64
primitive or its abs
method would have solved this for me. Maybe in a # Caveats
section?
Metadata
Metadata
Assignees
Labels
Area: Documentation for any part of the project, including the compiler, standard library, and toolsArea: `#[stable]`, `#[unstable]` etc.Category: An issue proposing an enhancement or a PR with one.Relevant to the library API team, which will review and decide on the PR/issue.Relevant to the rustdoc team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
[-]Document item stability of `f64::abs` in no std crates[/-][+]Document path stability of `f64::abs` in no std crates[/+]RalfJung commentedon Mar 28, 2025
Cc @rust-lang/rustdoc @rust-lang/libs-api
GuillaumeGomez commentedon Mar 31, 2025
This is indeed pretty bad. I'll try to take a look whenever I have time if no one did until then.
DJMcNab commentedon May 20, 2025
Linking to #137578 and #50145, which are both are recent cases where this kind of issue can occur.
I talked about this with @joshtriplett at the RustWeek unconference - in Linebender we have run into similar issues.
Josh also suggested that the other way around would be helpful. That is, somehow displaying in
std::f64::abs
that it is also available incore
. This would be a natural extension of this issue, as this would want to use the same MSRV-awareness infrastructure in that display.(Ideally, something like Clippy would also suggest that you use are using an item from std which is also in core, which it can only correctly do if it knows when it moved to core).
lopopolo commentedon May 20, 2025
CStr
is another such example:And
OsStr
:tgross35 commentedon May 28, 2025
A note in the docs is probably sufficient to cover this case until we get something first class (if we decide we still need that), since the circumstances here are relatively uncommon. E.g: This method is available in
core
only since 1.x.0. Before then, it was only usable instd
.