Skip to content

Tracking Issue for assert_eq in constants #74925

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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: An issue tracking the progress of sth. like the implementation of an RFC

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: An issue tracking the progress of sth. like the implementation of an RFC 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).

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC
Projects
None yet
Development

No branches or pull requests

5 participants