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

Constify assert_eq! and assert_ne! #103639

Closed
wants to merge 3 commits into from

Conversation

fee1-dead
Copy link
Member

@fee1-dead fee1-dead commented Oct 27, 2022

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
Copy link
Collaborator

rustbot commented Oct 27, 2022

r? @thomcc

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

@rustbot 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 Oct 27, 2022
@rustbot
Copy link
Collaborator

rustbot commented Oct 27, 2022

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

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Oct 31, 2022

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

@thomcc
Copy link
Member

thomcc commented Nov 4, 2022

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
Copy link
Contributor

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

@rustbot label -T-compiler

@rustbot rustbot removed the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Nov 29, 2022
@fee1-dead
Copy link
Member Author

r? libs

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Jan 7, 2023

☔ 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), "`"));
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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 .

@Mark-Simulacrum
Copy link
Member

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

@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 21, 2023
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
@fee1-dead
Copy link
Member Author

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 27, 2023
@bors
Copy link
Contributor

bors commented Feb 4, 2023

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

@a1phyr
Copy link
Contributor

a1phyr commented Feb 10, 2023

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.

@fee1-dead fee1-dead marked this pull request as draft February 25, 2023 10:15
@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 25, 2023
@fee1-dead fee1-dead closed this Mar 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants