Skip to content
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

Tracking Issue for assert_eq in constants #74925

Closed
oli-obk opened this issue Jul 29, 2020 · 5 comments
Closed

Tracking Issue for assert_eq in constants #74925

oli-obk opened this issue Jul 29, 2020 · 5 comments
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature.

Comments

@oli-obk
Copy link
Contributor

oli-obk commented Jul 29, 2020

In order to use assert_eq! in constants, we first need to have panic! with formatting (#51999) and const fn PartialEq::eq implementations (#67792) implemented and stabilized. If you look at the desugaring of assert_eq!, this quickly becomes obvious:

assert_eq!(a, b);

desugars to

        match (&a, &b) {
            (left_val, right_val) => {
                if !(*left_val == *right_val) {
                    // The reborrows below are intentional. Without them, the stack slot for the
                    // borrow is initialized even before the values are compared, leading to a
                    // noticeable slow down.
                    panic!(r#"assertion failed: `(left == right)`
  left: `{:?}`,
 right: `{:?}`"#, &*left_val, &*right_val)
                }
            }
        }

where the == operation will desugar to PartialEq::eq(left_val, right_val) for all non-primites. If we want to, we can support assert_eq! for primitives (integers, chars, bools) with only panicking with formatting.

@oli-obk oli-obk added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Jul 29, 2020
@mental32
Copy link
Contributor

@oli-obk does this only apply to assert_eq or does it cover all of assert/assert_eq/assert_ne/debug_* variants?

@oli-obk
Copy link
Contributor Author

oli-obk commented Aug 26, 2020

It covers all of these unless there's no formatting in assert or debug_assert, then those will work even without the formatting part of #51999

@lcnr
Copy link
Contributor

lcnr commented Sep 16, 2022

discussed in a compiler meeting: https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bsteering.20meeting.5D.202022-09-16.20JIT.20backlog.20b'za/near/299173821

closing as the information provided here is also part of the const-eval skill tree where it's probably more discoverable: https://rust-lang.github.io/const-eval/

@lcnr lcnr closed this as completed Sep 16, 2022
@ilyvion
Copy link

ilyvion commented Oct 23, 2023

  1. For some reason, this "const-eval skill tree" is presented so small as to be basically unreadable:
    image
  2. There's no instructions on how to read this thing anyway, so even if I could read the text in the dark orange/brown boxes, I'm not sure what it's supposed to be telling me about why I can't use assert_eq! in a const context.
  3. As far as I can tell, based on the error you get, the problem is that there's a call to a non-const function core::panicking::assert_failed, and although this issue was closed over a year ago, it's still happening in Rust today.

@ChrisDenton
Copy link
Member

As the OP says, this is requires const traits (#67792).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature.
Projects
None yet
Development

No branches or pull requests

5 participants