[rustdoc] Don't try to print the value of a non-primitive const #150629

yotamofek · 2026-01-02T22:20:30Z

r? @fmease maybe? (feel free to re-assign, ofc 😁)
Pretty new to these parts of the code, so I have no idea if this is an acceptable fix.
Fixes #150312

rustbot · 2026-01-02T22:20:35Z

fmease is not on the review rotation at the moment.
They may take a while to respond.

yotamofek · 2026-01-04T12:11:23Z

@GuillaumeGomez are you free to take a look, maybe?

fmease · 2026-01-04T12:16:01Z

NB: We might want to cease calling const_eval_poly outright to address #149635 (comment) (thereby fixing 3 GH issues) which would automatically fix the issue linked to this PR (so +1 = 4).

More concretely, for provided assoc consts we should just print = _ unless it's already a (HIR) literal (i.e., pre evaluation) in which case we can print = $LIT where $LIT is the literal (for cross-crate consts we might need to fall back to _ in all cases, not quite sure atm). Most importantly, we would stop eval'ing those consts via const_eval_poly which should also improve perf tremendously (cc #95316 (comment)).

fmease · 2026-01-04T12:21:57Z

Would you be interested in spinning up such an alternative PR?

yotamofek · 2026-01-04T12:36:47Z

Would you be interested in spinning up such an alternative PR?

Yes! Not sure when I'll get to it, but I'll be happy to take a look. Thanks!

GuillaumeGomez · 2026-01-04T13:59:26Z

tests/rustdoc-html/non-primitive-assoc-const-150312.rs

@@ -0,0 +1,18 @@
+#![crate_name = "foo"]


Also please add a comment explaining what this is testing (we should maybe enforce that in all tests).

GuillaumeGomez · 2026-01-04T14:00:21Z

Fix looks good to me but my knowledge in this part of the code is quite limited so letting @fmease handle it. ;)

yotamofek · 2026-01-04T21:05:37Z

More concretely, for provided assoc consts we should just print = _ unless it's already a (HIR) literal (i.e., pre evaluation) in which case we can print = $LIT where $LIT is the literal (for cross-crate consts we might need to fall back to _ in all cases, not quite sure atm). Most importantly, we would stop eval'ing those consts via const_eval_poly which should also improve perf tremendously (cc #95316 (comment)).

Hey @fmease, I'm messing around with this, and want to make sure you've taken the consequences into account:
if we stop calling const_eval_poly, we'll be losing the ability to display the results of simple, compile-time, primitive-typed calculations. Stuff like const A: usize = 10 + 20; would be rendered in docs as const A: usize = _;, which seems a bit of a shame.

There are probably more examples even in the STD docs, but this is one that I found quite quickly: https://doc.rust-lang.org/stable/std/primitive.f32.html#associatedconstant.INFINITY

fmease · 2026-01-04T21:25:29Z

Thanks for reaching out! Yes, indeed, those are the consequences unfortunately. However note that prior to PR #95316 (2022) we didn't show anything; now we would at least still show simple literals.

If you think about it, starting to eagerly evaluate associated constants (even in generic contexts) was technically speaking a correctness regression. It's reasonable that users expect assoc consts to be evaluated post-mono & only when referenced just like during normal compilation. Currently we're rejecting valid patterns (like setting an assoc const to panic!()) that rustc accepts.

I knew about this issue for quite a while but I never got around to fixing it the way I'm proposing now because I've always hoped that we'd introduce new "control" #[doc(...)] attributes before that (see e.g., binarycat's draft RFC 3770 (there were discussions already years before that on Zulip)).

rustbot · 2026-01-04T22:06:52Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

yotamofek · 2026-01-04T22:09:24Z

@fmease took initiative and decided to try and also print hir::ExprKind::Path because.. why not? (you'll probably think of a good reason to not do that, haha)

marking as draft since it's not ready for proper review, but I would like to see if you like the direction this is going, specifically - if you could review the changes to the tests to see that this is what you meant.

yotamofek · 2026-01-04T22:10:50Z

BTW, print_evaluated_const (and const_eval_poly) is still used by rustdoc-json, and I'm not touching that right now.

fmease · 2026-01-11T19:42:27Z

src/librustdoc/html/render/print_item.rs

            let tcx = cx.tcx();
            render_attributes_in_code(w, it, "", cx)?;

+            let val = fmt::from_fn(|f| {


Note that we could continue using c.value() for free const items that don't have non-lifetime (generic) parameters since rustc evaluates them already anyway. 🤷 As I've said in a bunch of comments, we definitely want to stop evaluating associated const items by default.

However, if you consider it not worth the complexity we can leave like this for the time being.

Right, sorry about that, managed to get a bit lost on the way :)
Let me try to implement it and we'll see just how complex it ends up.

Addendum

I've now actually reviewed the code & have realized that you've modified item_constant which is called for free const items only (for assoc consts, it's fn assoc_const in render/mod.rs).

I actually want to take a step back. Your PR was originally only wanted to fix #150312 (ValTree's dbg repr leaking through) but I steered you towards also addressing the "diverging assoc consts" issues while you're at it. As a result, it feels a bit tangled & confusing to me. I'm sorry about that.

I'll spin up a separate PR that exclusively fixes the new regression and doesn't try to restrict the kinds of const exprs since the latter doesn't have any time pressure.

Feel free to revert back to the initial version which I can then review w/o having the "divering assoc consts" issues in mind.

fmease · 2026-01-16T18:30:19Z

src/librustdoc/clean/utils.rs

+    matches!(
+        tcx.hir_node(hir_id),
+        Node::Expr(Expr {
+            kind: Lit(_) | Path(_) | Unary(UnOp::Neg, Expr { kind: Lit(_) | Path(_), .. }),


Path is hardly a primitive. We might want to rename this function to is_simple_expr.

fmease · 2026-01-16T19:09:21Z

src/librustdoc/clean/utils.rs

 ) -> Option<String> {
    tcx.const_eval_poly(def_id).ok().and_then(|val| {
        let ty = tcx.type_of(def_id).instantiate_identity();
+        if !ty.is_primitive() {


This doesn't include all types that have literals, meaning it's stricter than is_literal_expr leading us to display fewer kinds of literals if extern compared to local.

Having the filter after const_eval_poly means we're still evaluating assoc (and free) const items that were cross-crate inlined meaning it doesn't address the recent regression & its older "duplicates".

fmease · 2026-01-16T19:51:54Z

src/librustdoc/html/render/print_item.rs

            let tcx = cx.tcx();
            render_attributes_in_code(w, it, "", cx)?;

+            let val = fmt::from_fn(|f| {


Addendum

I've now actually reviewed the code & have realized that you've modified item_constant which is called for free const items only (for assoc consts, it's fn assoc_const in render/mod.rs).

I actually want to take a step back. Your PR was originally only wanted to fix #150312 (ValTree's dbg repr leaking through) but I steered you towards also addressing the "diverging assoc consts" issues while you're at it. As a result, it feels a bit tangled & confusing to me. I'm sorry about that.

I'll spin up a separate PR that exclusively fixes the new regression and doesn't try to restrict the kinds of const exprs since the latter doesn't have any time pressure.

Feel free to revert back to the initial version which I can then review w/o having the "divering assoc consts" issues in mind.

fmease · 2026-01-16T20:20:30Z

Let's wait for my "diverging assoc consts" PR, so we can see what's truly needed afterwards. Thanks for your understanding :)

@rustbot blocked

@cuviper

…mofek rustdoc: Stop unconditionally evaluating the initializer of associated consts See the descriptions of the added tests for details. Fixes #131625. Fixes [after beta-1.93 backport] #149635. Fixes #150312. Supersedes #150629 IINM. CC @cuviper (#149635 (comment)) r? @GuillaumeGomez or @yotamofek (#150629)

rustbot assigned fmease Jan 2, 2026

fmease mentioned this pull request Jan 4, 2026

panic in constant evaluation while documenting default associated constant #149635

Open

fmease added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 4, 2026

GuillaumeGomez approved these changes Jan 4, 2026

View reviewed changes

GuillaumeGomez reviewed Jan 4, 2026

View reviewed changes

yotamofek force-pushed the pr/rustdoc/fix-150312 branch from b127b9f to d03698f Compare January 4, 2026 22:06

yotamofek marked this pull request as draft January 4, 2026 22:07

This comment has been minimized.

Sign in to view

This comment was marked as resolved.

Sign in to view

yotamofek added 3 commits January 7, 2026 22:11

[rustdoc] Don't try to print the value of a non-primitive const

fa93dbd

wip

fe10b22

fix rustdoc-ui tests

d6018cf

yotamofek force-pushed the pr/rustdoc/fix-150312 branch from bfe62e7 to d6018cf Compare January 7, 2026 20:11

fmease reviewed Jan 11, 2026

View reviewed changes

fmease reviewed Jan 16, 2026

View reviewed changes

rustbot added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 16, 2026

rust-lang deleted a comment from rust-bors bot Jan 16, 2026

fmease mentioned this pull request Jan 17, 2026

rustdoc: Stop unconditionally evaluating the initializer of associated consts #151232

Open

Uh oh!

[rustdoc] Don't try to print the value of a non-primitive const #150629

Are you sure you want to change the base?

[rustdoc] Don't try to print the value of a non-primitive const #150629

Uh oh!

Conversation

yotamofek commented Jan 2, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jan 2, 2026

Uh oh!

yotamofek commented Jan 4, 2026

Uh oh!

fmease commented Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fmease commented Jan 4, 2026

Uh oh!

yotamofek commented Jan 4, 2026

Uh oh!

GuillaumeGomez Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

GuillaumeGomez commented Jan 4, 2026

Uh oh!

yotamofek commented Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fmease commented Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jan 4, 2026

Uh oh!

yotamofek commented Jan 4, 2026

Uh oh!

yotamofek commented Jan 4, 2026

Uh oh!

This comment has been minimized.

This comment was marked as resolved.

This comment was marked as resolved.

fmease Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

yotamofek Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

fmease Jan 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Addendum

Uh oh!

fmease Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

fmease Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

fmease Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

fmease Jan 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Addendum

Uh oh!

fmease commented Jan 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

yotamofek commented Jan 2, 2026 •

edited by rustbot

Loading

fmease commented Jan 4, 2026 •

edited

Loading

yotamofek commented Jan 4, 2026 •

edited

Loading

fmease commented Jan 4, 2026 •

edited

Loading

fmease Jan 16, 2026 •

edited

Loading

fmease Jan 16, 2026 •

edited

Loading

fmease commented Jan 16, 2026 •

edited

Loading