Skip to content

Broken docs for std-detect on docs.rs #1799

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

Open
VorpalBlade opened this issue May 16, 2025 · 5 comments
Open

Broken docs for std-detect on docs.rs #1799

VorpalBlade opened this issue May 16, 2025 · 5 comments

Comments

@VorpalBlade
Copy link

https://docs.rs/crate/std_detect/latest reads:

"std_detect-0.1.5 doesn't have any documentation".

I suspect this is what breaks the source link from https://doc.rust-lang.org/stable/std/macro.is_x86_feature_detected.html

(Why that points to "latest" instead of the version std actually uses I have no idea, that seems quite unfortunate).

See also rust-lang/rust#141102 which is how I discovered this.

@bjorn3
Copy link
Member

bjorn3 commented May 17, 2025

The crates.io version of std-detect should never be used.

(Why that points to "latest" instead of the version std actually uses I have no idea, that seems quite unfortunate).

This is what we should fix instead.

@VorpalBlade
Copy link
Author

VorpalBlade commented May 17, 2025

The crates.io version of std-detect should never be used.

  • But the docs on docs.rs shouldn't be broken when they are on there.
  • The docs that are on docs.rs read as follows:

If you need run-time feature detection in #[no_std] environments, Rust core library cannot help you. By design, Rust core is platform independent, but performing run-time feature detection requires a certain level of cooperation from the platform.

You can then manually include std_detect as a dependency to get similar run-time feature detection support than the one offered by Rust's standard library. We intend to make std_detect more flexible and configurable in this regard to better serve the needs of #[no_std] targets.

This indicates to me that the crates.io version can be used if you are working with for example x86_64-none-linux-gnu, that is you are on an OS (such as Linux) but not using libc (e.g. you are implementing your own libc in rust).

I'm not sure if std-detect would work if you don't have an OS (e.g. bare metal when implementing a kernel or in embedded): that is why I was trying to look at the source of the macro in the first place, to figure out if it used cpuid directly or read data from the OS.

If that isn't what the docs mean, I think the wording on https://docs.rs/crate/std_detect/latest should be updated to make that explicit.

This is what we should fix instead.

Agreed, but both issues should be fixed.

@bjorn3
Copy link
Member

bjorn3 commented May 17, 2025

On most architectures std_detect is forced to use OS api's as the cpuid equivalent is not accessible from userspace. x86 is basically the only exception (though inside sgx enclaves cpuid isn't a thing there either)

@VorpalBlade
Copy link
Author

Then the "no-std on OS" use case remains (which is quite niche, and outside of Linux virtually non-existent unless you are the OS vendor).

@lolbinarycat
Copy link

(Why that points to "latest" instead of the version std actually uses I have no idea, that seems quite unfortunate).

its because that's the url rustdoc is being passed via --extern-html-root-url

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants