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

Associated constant formatting in docs should mirror source #42759

Closed
SergioBenitez opened this issue Jun 19, 2017 · 1 comment
Closed

Associated constant formatting in docs should mirror source #42759

SergioBenitez opened this issue Jun 19, 2017 · 1 comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@SergioBenitez
Copy link
Contributor

In my source code, I've declared an associated constant as follows:

struct MyStruct(u8);

impl MyStruct {
    pub const KIND: MyStruct = MyStruct(0b0100);
}

If I render the rustdocs for MyStruct, the following is displayed:

KIND: MyStruct = MyStruct(4)

Instead, I would like to see:

KIND: MyStruct = MyStruct(0b0100)

Or, at the very least:

KIND: MyStruct = MyStruct(0b100)

I've declared the KIND constant as a binary number because it serves as a mask. I want the rustdocs to reflect this. Said another way, the representation used in the source code is meaningful, and the rustdocs should preserve that meaning. Note that this should also apply to other representations including hexadecimal. This format-preserving behavior should also apply to other constants, not just associated constants.

@steveklabnik steveklabnik added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. labels Jun 19, 2017
@Mark-Simulacrum Mark-Simulacrum added C-feature-request Category: A feature request, i.e: not implemented / a PR. C-enhancement Category: An issue proposing an enhancement or a PR with one. and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Jul 27, 2017
@ollie27
Copy link
Member

ollie27 commented Nov 22, 2019

Fixed by #53409. We don't show the values of consts anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. 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