Skip to content
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

rustdoc: Named constants in array sizes shouldn't be evaluated #102456

Open
jmillikin opened this issue Sep 29, 2022 · 3 comments
Open

rustdoc: Named constants in array sizes shouldn't be evaluated #102456

jmillikin opened this issue Sep 29, 2022 · 3 comments
Assignees
Labels
C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@jmillikin
Copy link
Contributor

jmillikin commented Sep 29, 2022

Current rustdoc behavior

Given the following code:

pub struct SomeStruct { _p: () }

#[cfg(target_os = "linux")]
const TARGET_STORAGE_SIZE: usize = 128;
#[cfg(not(target_os = "linux"))]
const TARGET_STORAGE_SIZE: usize = 256;

impl SomeStruct {
    /// How much storage to allocate for a call to
    /// [`some_method`](Self::some_method).
    pub const STORAGE_SIZE: usize = TARGET_STORAGE_SIZE;

    /// The user is expected to call this with an array of size
    /// `SomeStruct::STORAGE_SIZE`, whatever that happens to be.
    pub fn some_method(
        &self,
        storage: &mut [u8; SomeStruct::STORAGE_SIZE],
    ) {}
}

The user would be expected to call it like this:

let mut storage = [0u8; SomeStruct::STORAGE_SIZE];
some_struct.some_method(&mut storage);

Unfortunately, the rustdoc output is confusing because it evaluates the constant when formatting the function signature:

rustdoc-1

If a user were to copy-paste from the rustdoc'd function signature when writing the call site, they would write code like this, which would fail to compile on some platforms:

let mut storage = [0u8; 128];
some_struct.some_method(&mut storage);

Proposed new behavior

A better way to format this function signature would be to use the constant's name, if the constant is public:

rustdoc-2

An even niftier formatting would let the constant become a link:

rustdoc-3

@jmillikin jmillikin added the C-bug Category: This is a bug. label Sep 29, 2022
@GuillaumeGomez GuillaumeGomez added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Sep 29, 2022
@fmease
Copy link
Member

fmease commented Oct 7, 2022

This strongly relates to the ongoing discussion around the formatting of constant values and expressions in rustdoc. I am in the process of writing an RFC (I've finally found time to start working on it). Your issue would fit in the drawbacks / alternatives section.

I won't assign myself to this issue since I am already assigned to too many issues related to this topic and no decisions have been reached yet and everything is very much in flux, hence the planned RFC.

See also: Zulip discussion, #98929

@fmease
Copy link
Member

fmease commented Jun 25, 2023

@JohnScience
Copy link
Contributor

Agreed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants