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

Modifies the rendering of constant values in rustdoc. #112167

Closed
wants to merge 4 commits into from

Conversation

sladyn98
Copy link
Contributor

@sladyn98 sladyn98 commented Jun 1, 2023

Previously, non-literal expressions (like 50 + 50) would be printed alongside their value as a comment (like = _; // 100i32). This approach often resulted in confusing documentation, especially for complex expressions.

To improve clarity, this commit changes the rendering to display the evaluated value of the expression directly (like = 100i32;) unless the constant is a literal expression. The original expression is still included as a comment if it
doesn't match the evaluated value.

These changes aim to improve the readability and usefulness of constant value documentation generated by rustdoc.

@rustbot
Copy link
Collaborator

rustbot commented Jun 1, 2023

r? @GuillaumeGomez

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jun 1, 2023
@sladyn98
Copy link
Contributor Author

sladyn98 commented Jun 1, 2023

CC @fmease

if let Some(value) = &value {
let value_lowercase = value.to_lowercase();
let expr_lowercase = expr.to_lowercase();
let value_lowercase = value.as_ref().map(|s| s.to_lowercase());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In your earlier PR I meant to suggest removing the entire branch including the body (the // business) not just the if-condition, sorry if that wasn't clear. This here still prints 3i32 // 3i32 for 1 + 2 if I'm not mistaken.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct that makes sense, sorry if I might not have understood it earlier.

13: @!hasraw check failed
	`PATTERN` did not match
	// @!hasraw show_const_contents/constant.CONST_I32_HEX.html ';'
50: @hasraw check failed
	`PATTERN` did not match
	// @hasraw show_const_contents/constant.PI.html '= 3.14159265358979323846264338327950288f32;'
51: @hasraw check failed
	`PATTERN` did not match
	// @hasraw show_const_contents/constant.PI.html '; // 3.14159274f32'

These tests still seem to be failing, should the code be suggesting something else, I am a bit confused on what the correct comment should be here

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@fmease
Copy link
Member

fmease commented Jun 5, 2023

Wondering if you need help with the failing test or is everything all good?

@sladyn98
Copy link
Contributor Author

sladyn98 commented Jun 5, 2023

@fmease Yeah I am not sure how to actually make it pass : )

@fmease
Copy link
Member

fmease commented Jun 6, 2023

Yeah I am not sure how to actually make it pass : )

Here's a diff:

diff --git a/tests/rustdoc/show-const-contents.rs b/tests/rustdoc/show-const-contents.rs
index 96a47218e0a..28a63de4b75 100644
--- a/tests/rustdoc/show-const-contents.rs
+++ b/tests/rustdoc/show-const-contents.rs
@@ -2,53 +2,43 @@
 // documentation.
 
 // @hasraw show_const_contents/constant.CONST_S.html 'show this'
-// @!hasraw show_const_contents/constant.CONST_S.html '; //'
 pub const CONST_S: &'static str = "show this";
 
 // @hasraw show_const_contents/constant.CONST_I32.html '= 42;'
-// @!hasraw show_const_contents/constant.CONST_I32.html '; //'
 pub const CONST_I32: i32 = 42;
 
 // @hasraw show_const_contents/constant.CONST_I32_HEX.html '= 0x42;'
-// @!hasraw show_const_contents/constant.CONST_I32_HEX.html ';'
 pub const CONST_I32_HEX: i32 = 0x42;
 
 // @hasraw show_const_contents/constant.CONST_NEG_I32.html '= -42;'
-// @!hasraw show_const_contents/constant.CONST_NEG_I32.html '; //'
 pub const CONST_NEG_I32: i32 = -42;
 
 // @hasraw show_const_contents/constant.CONST_EQ_TO_VALUE_I32.html '= 42i32;'
-// @!hasraw show_const_contents/constant.CONST_EQ_TO_VALUE_I32.html '// 42i32'
 pub const CONST_EQ_TO_VALUE_I32: i32 = 42i32;
 
 // @hasraw show_const_contents/constant.CONST_CALC_I32.html '= 43i32'
 pub const CONST_CALC_I32: i32 = 42 + 1;
 
 // @!hasraw show_const_contents/constant.CONST_REF_I32.html '= &42;'
-// @!hasraw show_const_contents/constant.CONST_REF_I32.html '; //'
 pub const CONST_REF_I32: &'static i32 = &42;
 
 // @hasraw show_const_contents/constant.CONST_I32_MAX.html '= 2_147_483_647i32'
 pub const CONST_I32_MAX: i32 = i32::MAX;
 
 // @!hasraw show_const_contents/constant.UNIT.html '= ();'
-// @!hasraw show_const_contents/constant.UNIT.html '; //'
 pub const UNIT: () = ();
 
 pub struct MyType(i32);
 
 // @!hasraw show_const_contents/constant.MY_TYPE.html '= MyType(42);'
-// @!hasraw show_const_contents/constant.MY_TYPE.html '; //'
 pub const MY_TYPE: MyType = MyType(42);
 
 pub struct MyTypeWithStr(&'static str);
 
 // @!hasraw show_const_contents/constant.MY_TYPE_WITH_STR.html '= MyTypeWithStr("show this");'
-// @!hasraw show_const_contents/constant.MY_TYPE_WITH_STR.html '; //'
 pub const MY_TYPE_WITH_STR: MyTypeWithStr = MyTypeWithStr("show this");
 
-// @hasraw show_const_contents/constant.PI.html '= 3.14159265358979323846264338327950288f32;'
-// @hasraw show_const_contents/constant.PI.html '; // 3.14159274f32'
+// @hasraw show_const_contents/constant.PI.html '= 3.14159274f32;'
 pub use std::f32::consts::PI;
 
 // @hasraw show_const_contents/constant.MAX.html '= 2_147_483_647i32'

As seen in the diff I've removed most @!hasraw checks not necessarily because they were required to make the test pass (there were only 3 test failures) but since they've become obsolete (technically only CONST_I32_HEX & PI needed to be modified).

@sladyn98 sladyn98 requested a review from fmease June 7, 2023 07:56
Copy link
Member

@fmease fmease left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good from my side. @GuillaumeGomez Do the broader changes still make sense to you (removal of //, showing the actual value of PI etc.)? TTBOMK, they are a natural consequence of fixing this FIXME. Edit: Maybe the commits should be squashed though?

@GuillaumeGomez
Copy link
Member

I think it's fine. Just in case, does it look ok to you @jsha, @Manishearth ?

@Manishearth
Copy link
Member

Honestly i think this depends on the constant: in some cases the source of the constant is more important (especially when it's platform-dependent!), in others the value is more important. I find the current display of expression AND value to be quite useful, and focusing on the expression is important because the value may change!

So I don't think this change is that great as-is. I would be open to someone RFCing an attribute that lets people control this behavior.

I'm not strongly of this behavior, I am strongly of the behavior that for non-literal constant the expression must be shown somewhere (or we show neither the expression nor the value: otherwise just a value may be misleading), so I'm willing to be convinced.

@fmease
Copy link
Member

fmease commented Jun 7, 2023

Manishearth's view is quite important and I agree with him to a not insignificant extend. We've had extensive discussion about this in the past. Intent (unevaluated expression) vs. representation (evaluated expression), e.g. on Zulip, topic new const display, and on my blocked PR #99688. Initially I was a big proponent of evaluating consts but over time I've shifted my opinion slightly and I'm no longer sure what the best way forward is. That's why I haven't written any RFC yet (as promised in #99688), though I also feel a bit guilty about it.

Looking at other parts of rustdoc, we also don't normalize assoc tys for example. There's -Znormalize-docs, maybe we could gate this PR's behavior behind it?? As a temporary solution until we intro a new #[doc] attribute or similar.

Sorry sladyn98 that you stumbled into this controversial topic. Edit: Before seeing the actual changes to the const-value-display test, I didn't fully realize we stepped into this territory again 🤦.

@Manishearth
Copy link
Member

Yeah I'm extremely in favor of a new attribute here because I think it's important to give people control over this.

@sladyn98
Copy link
Contributor Author

sladyn98 commented Jun 7, 2023

No worries let me know if you want to close this PR in favor of another one, or need any more help adding stuff. Thanks

@Manishearth
Copy link
Member

I think it's probably fine to close this PR for now and instead join the Zulip discussion led by @fmease here

@sladyn98 sladyn98 closed this Jun 8, 2023
@sladyn98
Copy link
Contributor Author

sladyn98 commented Jun 8, 2023

Closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants