-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
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()); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Wondering if you need help with the failing test or is everything all good? |
@fmease 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 |
There was a problem hiding this 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?
I think it's fine. Just in case, does it look ok to you @jsha, @Manishearth ? |
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 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. |
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 Sorry sladyn98 that you stumbled into this controversial topic. Edit: Before seeing the actual changes to the |
Yeah I'm extremely in favor of a new attribute here because I think it's important to give people control over this. |
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 |
Closed |
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.