-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Constify assert_eq!
and assert_ne!
#103639
Conversation
r? @thomcc (rustbot has picked a reviewer for you, use r? to override) |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
This comment has been minimized.
This comment has been minimized.
7b4bc71
to
e0e35db
Compare
This comment has been minimized.
This comment has been minimized.
e0e35db
to
3749356
Compare
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #103787) made this pull request unmergeable. Please resolve the merge conflicts. |
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 |
I am not sure this needs T-compiler review/signoff. In case, please re-add the team, thanks :) @rustbot label -T-compiler |
r? libs |
b48319c
to
2353dcf
Compare
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #105323) made this pull request unmergeable. Please resolve the merge conflicts. |
@@ -105,7 +105,7 @@ macro_rules! assert_ne { | |||
// 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. | |||
$crate::panicking::assert_failed(kind, &*left_val, &*right_val, $crate::option::Option::Some($crate::format_args!($($arg)+))); | |||
$crate::panicking::assert_failed(kind, &*left_val, &*right_val, $crate::option::Option::Some($crate::format_args!($($arg)+)), $crate::concat!("assertion failed: `", $crate::stringify!($left), " != ", $crate::stringify!($right), "`")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means that at compile-time, assert_eq/ne will print the stringify'd form of the values, rather than Debug format them, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, because we can't format the actual values in compile time unless there is a way to make Display
const.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 .
Is this immediately accessible on stable? If not, is there a test validating that already? |
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
2353dcf
to
89dac4c
Compare
@rustbot ready |
☔ The latest upstream changes (presumably #107267) made this pull request unmergeable. Please resolve the merge conflicts. |
Preview work on #79100 showed that these macros are quite perf-sensitive, and adding a |
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.