rustdoc: Fix inconsistencies in `const` value rendering

[camelid]

The topic of this issue has changed since it was first opened. See #83035 (comment) for a more up-to-date summary.

---

The way they're displayed is both different (one use a BodyId whereas the other is forced to use its DefId. But ultimately, it'd be nice to be able to merge them.

Originally posted by @GuillaumeGomez in #82873 (comment)

This will be done after #82873 is merged.

[camelid]

PR is merged!

[GuillaumeGomez]

Do you want to work on it? Otherwise I'll do it. :)

[camelid]

I'm hoping to work on it, but if I don't get to it I'll try to let you know so you can do it :)

[GuillaumeGomez]

Well, please tell me if you change your mind. A lot of other things to do. ;)

[camelid]

I'm working on this now, and I noticed that statics use only a BodyId. When they come from another crate, their value is set to None. Why are constants and statics treated differently here?

[camelid]

I think the code would be greatly simplified if we always evaluated constants. I.e., currently something like const FOO: usize = 1 + 2; will render as

const FOO: usize = 1 + 2; // 3usize

I don't think showing the 1 + 2 is that valuable—unless there are cases where it's valuable? Instead, I suggest we just show

const FOO: usize = 3;

I think this is the difference between ConstantKind::expr and ConstantKind::value: expr shows the pretty-printed source, while value shows the evaluated constant.

[camelid]

One weird thing is that we print the values of some constants, but not others. E.g., we seem to print &str constants, but not custom struct constants.

[camelid]

Wow, we literally store rendered constant initializers in crate metadata just for rustdoc. So, not showing the pretty-printed version, or only showing it for local items, would probably reduce crate metadata size somewhat significantly.

[camelid]

I think as a team we should have a discussion about if we want to change constant rendering. I think the current logic is confusing both to end users and to people who work on the code.

For example, the initializer of const FOO: i32 = 42; is rendered, but the initializer of const FOO: &'static i32 = &42; is not (no value is shown, just a semicolon). That behavior seems arbitrary and confusing.

As another example, const FOO: () = (); renders as just const FOO: (); for some reason.

Furthermore, a re-export of std::i32::MAX renders as pub const MAX: i32 = i32::MAX; // 2_147_483_647i32. The i32::MAX is not clickable.

A re-export of std::f32::consts::PI renders as pub const PI: f32 = 3.14159265358979323846264338327950288f32; // 3.14159274f32. I'm not sure why it shows both the pretty-printed constant as well as the evaluated constant, which is different from the behavior of const FOO: u32 = 42;.

[GuillaumeGomez]

I don't think showing the 1 + 2 is that valuable—unless there are cases where it's valuable? Instead, I suggest we just show

I agree, printing the value directly would be more interesting. If they want to see the original code, they can see the source.

Overall, there is a lot of cleanup to do apparently. I'm surprised we didn't detect all those weird behaviours before but I'm glad you did. So except for keeping the original value in the const and show the computed value as a code comment, I think you can just ahead for the rest.