Constify assert_eq! and assert_ne!

[fee1-dead]

We provide an inferior type of formatting for use when panicking in compile time, which should not come with additional costs as the additional argument should be inlined and optimized away when in runtime.

As for additional code in assert_failed: this is an implementation detail that is hard to find and not intended to be exposed anyways, so I don't think it will hurt readability much.

[rustbot]

r? @thomcc

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

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[bors]

☔ The latest upstream changes (presumably #103787) made this pull request unmergeable. Please resolve the merge conflicts.

[thomcc]

Rerolling this. I think it's a good idea but I'm not sure if this is "api change" or "just let wg-const-eval do their thing"

r? libs

[apiraino]

I am not sure this needs T-compiler review/signoff. In case, please re-add the team, thanks :)

@rustbot label -T-compiler

[fee1-dead]

r? libs

[bors]

☔ The latest upstream changes (presumably #105323) made this pull request unmergeable. Please resolve the merge conflicts.

[Mark-Simulacrum]

This means that at compile-time, assert_eq/ne will print the stringify'd form of the values, rather than Debug format them, right?

[fee1-dead]

Yes, because we can't format the actual values in compile time unless there is a way to make Display const.

[est31]

But this PR requires us to always support the stringify fallback, no? That is, we won't be able to add a ~const Display requirement to the arguments in the future, if this PR is merged.

We might still support printing via specialization though, if ~const Display is available. Maybe, to ensure we've not painted ourselves into a corner, the stringify fallback could also be enabled via specialization on non-const contexts?

[fee1-dead]

What do you mean? This isn't and shouldn't be insta-stable, which means we can change the implementation should future developments allow const display.

[est31]

Oh right sorry I've missed the #[rustc_const_unstable(feature = "const_assert_eq", issue = "none")] annotation. Should also answer the question of @Mark-Simulacrum .

[Mark-Simulacrum]

Is this immediately accessible on stable? If not, is there a test validating that already?

[fee1-dead]

@rustbot ready

[bors]

☔ The latest upstream changes (presumably #107267) made this pull request unmergeable. Please resolve the merge conflicts.

[a1phyr]

Preview work on #79100 showed that these macros are quite perf-sensitive, and adding a concat! and two stringify! seems quite heavy.
I wouldn't merge this without a perf run.