Enforce syntactical stability of const traits in HIR #135423

compiler-errors · 2025-01-13T01:28:50Z

This PR enforces what I'm calling syntactical const stability of traits. In other words, it enforces the ability to name ~const/const traits in trait bounds in various syntax positions in HIR (including in the trait of an impl header). This functionality is analogous to the regular item stability checker, which is concerned with making sure that you cannot refer to unstable items by name, and is implemented as an extension of that pass.

This is separate from enforcing the recursive const stability of const trait methods, which is implemented in MIR and runs on MIR bodies. That will require adding a new NonConstOp to the const checker and probably adjusting some logic to deduplicate redundant errors.

However, this check is separate and necessary for making sure that users don't add ~const/const bounds to items when the trait is not const-stable in the first place. I chose to separate enforcing recursive const stability out of this PR to make it easier to review. I'll probably open a follow-up following this one, blocked on this PR.

r? @RalfJung cc @rust-lang/project-const-traits

rustbot · 2025-01-13T01:28:59Z

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @rust-lang/wg-const-eval

compiler-errors · 2025-01-13T02:01:11Z

compiler/rustc_middle/src/middle/stability.rs

            ),
            EvalResult::Unmarked => unmarked(span, def_id),
        }

        is_allowed
    }

+    pub fn check_const_stability(self, def_id: DefId, span: Span, const_kw_span: Span) {


This function is analogous to check_optional_stability but with the logic in eval_stability_allow_unstable inlined, and which operating on const stability instead of regular stability.

And I don't think we have soft unstability for consts, so I asserted against that.

That seems like a comment worth putting into the code.

RalfJung · 2025-01-13T07:23:15Z

Isn't #133999 doing essentially the same thing? Cc @fee1-dead

fee1-dead

lgtm

fee1-dead · 2025-01-13T07:48:18Z

This is separate from enforcing the recursive const stability of const trait methods, which is implemented in MIR and runs on MIR bodies. That will require adding a new NonConstOp to the const checker and probably adjusting some logic to deduplicate redundant errors.

FWIW, you can't do all the recursive stability checks in MIR. Currently, we allow something like

#[rustc_const_stable(feature = "dummy", since = "1.0.0")]
const fn foo<T: ~const UnstableTrait>() {  }

If the feature for that unstable trait is enabled. For recursive stability, we would need to check the bounds (which is different than running passes on MIR bodies). Several more places for this check would be const impls, const traits, and associated type bounds on const traits, etc.

compiler-errors · 2025-01-13T12:44:37Z

@RalfJung: Kind of, but no. This implements a subset of that PR in a totally different way, and I put it up bc @fee1-dead mentioned that they wouldn't have time to finish up this work.

compiler-errors · 2025-01-13T12:45:53Z

FWIW, you can't do all the recursive stability checks in MIR. [...]

@fee1-dead: I think that over complicates the problem a bit? Recursive const stability shouldn't need to be concerned with things that don't end up in the MIR, method calls in this case.

Simply adding a where clause to a function feels separate from that -- after all, isn't recursive const stability checking motivated by making sure we don't expose new const intrinsics (and other functionality that would make the evaluator do new things) to stable const Rust? naming a where clause does not feel like that to me.

RalfJung · 2025-01-13T18:36:37Z

Having talked with @compiler-errors, I agree with them. We should ensure that method calls follow the established recursive const stability rules, but the trait system so far hasn't done recursive stability and I don't think it has to start now.

What is important is that if Trait::method can be called from a stable const fn, then in all impls of trait, method follows recursive const stability rules.

RalfJung

I agree with the general approach and the test results look good. I'm not familiar enough with the implementation of our general stability checks to sign off on that, though.

r? compiler

tests/ui/consts/promoted_const_call.rs

RalfJung · 2025-01-14T08:18:06Z

compiler/rustc_middle/src/middle/stability.rs

            ),
            EvalResult::Unmarked => unmarked(span, def_id),
        }

        is_allowed
    }

+    pub fn check_const_stability(self, def_id: DefId, span: Span, const_kw_span: Span) {


That seems like a comment worth putting into the code.

RalfJung · 2025-01-14T08:21:53Z

Uh what, we got two reviewers?^^

r? compiler

oli-obk · 2025-01-14T10:57:21Z

r=me with ralf's nits

tests/ui/consts/promoted_const_call.rs

RalfJung · 2025-01-14T18:59:40Z

tests/ui/consts/promoted_const_call.stderr

Hm, this still completely changes the test results... what is this even testing?

See the PR I linked where oli fixed const promotion, it's just testing that we don't promote random things.

RalfJung · 2025-01-14T18:59:59Z

tests/ui/consts/promoted_const_call.rs

@@ -1,6 +1,6 @@
 //@ known-bug: #103507


This bug is long-closed. Something is fishy here.

I bet it was a typo lol

This is not a known bug, but actually just a check-fail test: #105085

I'll remvoe the known-bug.

That's concerning, how did that get added in the first place... this was in #114134.

We should probably check the other tests that reference that issue

tests/ui/consts/issue-94675.rs 1://@ known-bug: #103507 tests/ui/consts/const-block-const-bound.rs 1://@ known-bug: #103507 tests/ui/consts/promoted_const_call.rs 1://@ known-bug: #103507 tests/ui/impl-trait/normalize-tait-in-const.rs 1://@ known-bug: #103507

(not in this PR)

Just a sweeping change where almost everything const traits related was known bug as the impl was ripped out

tests/ui/consts/promoted_const_call.rs

RalfJung · 2025-01-14T20:59:49Z

@bors r=oli-obk,RalfJung

bors · 2025-01-14T20:59:52Z

📌 Commit 2743df8 has been approved by oli-obk,RalfJung

It is now in the queue for this repository.

rustbot assigned RalfJung Jan 13, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 13, 2025

compiler-errors commented Jan 13, 2025

View reviewed changes

fee1-dead approved these changes Jan 13, 2025

View reviewed changes

RalfJung reviewed Jan 14, 2025

View reviewed changes

rustbot assigned chenyukang and SparrowLii and unassigned chenyukang and RalfJung Jan 14, 2025

RalfJung mentioned this pull request Jan 14, 2025

rustbot assigned two reviewers rust-lang/triagebot#1881

Closed

rustbot assigned Nadrieril and unassigned chenyukang and SparrowLii Jan 14, 2025

oli-obk assigned oli-obk and unassigned Nadrieril Jan 14, 2025

compiler-errors force-pushed the enforce-const-trait-syntactical branch from 3cd9780 to 6c3c1e4 Compare January 14, 2025 18:53

compiler-errors commented Jan 14, 2025

View reviewed changes

tests/ui/consts/promoted_const_call.rs Outdated Show resolved Hide resolved

compiler-errors force-pushed the enforce-const-trait-syntactical branch from 6c3c1e4 to 55c1f36 Compare January 14, 2025 18:55

RalfJung reviewed Jan 14, 2025

View reviewed changes

Enforce syntactical stability of const traits in HIR

2743df8

compiler-errors force-pushed the enforce-const-trait-syntactical branch from 55c1f36 to 2743df8 Compare January 14, 2025 19:12

RalfJung reviewed Jan 14, 2025

View reviewed changes

tests/ui/consts/promoted_const_call.rs Show resolved Hide resolved

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 14, 2025

workingjubilee mentioned this pull request Jan 15, 2025

Rollup of 11 pull requests #135519

Merged

RalfJung mentioned this pull request Jan 15, 2025

const traits: remove some known-bug that do not seem to make sense #135523

Merged

bors merged commit 11ac57a into rust-lang:master Jan 15, 2025
6 checks passed

rustbot added this to the 1.86.0 milestone Jan 15, 2025

c410-f3r mentioned this pull request Jan 19, 2025

[generic_assert] "Constify" the Debug trait #135712

Closed

Randl mentioned this pull request Jan 30, 2025

Constify PartialEq #133995

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enforce syntactical stability of const traits in HIR #135423

Enforce syntactical stability of const traits in HIR #135423

compiler-errors commented Jan 13, 2025

rustbot commented Jan 13, 2025

compiler-errors Jan 13, 2025 •

edited

Loading

RalfJung Jan 14, 2025

RalfJung commented Jan 13, 2025

fee1-dead left a comment

fee1-dead commented Jan 13, 2025 •

edited

Loading

compiler-errors commented Jan 13, 2025 •

edited

Loading

compiler-errors commented Jan 13, 2025 •

edited

Loading

RalfJung commented Jan 13, 2025

RalfJung left a comment

RalfJung Jan 14, 2025

RalfJung commented Jan 14, 2025

oli-obk commented Jan 14, 2025

RalfJung Jan 14, 2025

compiler-errors Jan 14, 2025

RalfJung Jan 14, 2025

compiler-errors Jan 14, 2025

compiler-errors Jan 14, 2025

RalfJung Jan 14, 2025

RalfJung Jan 14, 2025

oli-obk Jan 14, 2025

RalfJung commented Jan 14, 2025

bors commented Jan 14, 2025

Enforce syntactical stability of const traits in HIR #135423

Enforce syntactical stability of const traits in HIR #135423

Conversation

compiler-errors commented Jan 13, 2025

rustbot commented Jan 13, 2025

compiler-errors Jan 13, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RalfJung commented Jan 13, 2025

fee1-dead left a comment

Choose a reason for hiding this comment

fee1-dead commented Jan 13, 2025 • edited Loading

compiler-errors commented Jan 13, 2025 • edited Loading

compiler-errors commented Jan 13, 2025 • edited Loading

RalfJung commented Jan 13, 2025

RalfJung left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RalfJung commented Jan 14, 2025

oli-obk commented Jan 14, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RalfJung commented Jan 14, 2025

bors commented Jan 14, 2025

compiler-errors Jan 13, 2025 •

edited

Loading

fee1-dead commented Jan 13, 2025 •

edited

Loading

compiler-errors commented Jan 13, 2025 •

edited

Loading

compiler-errors commented Jan 13, 2025 •

edited

Loading