-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
don't drop arguments' temporaries in dbg!
#154074
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not totally sure where this should go. Conceptually, it makes the most sense for it to be a |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| // ignore-tidy-dbg | ||
|
|
||
| /// Test for <https://github.com/rust-lang/rust/issues/153850>: | ||
| /// `dbg!` shouldn't drop arguments' temporaries. | ||
| #[test] | ||
| fn no_dropping_temps() { | ||
| fn temp() {} | ||
|
|
||
| *dbg!(&temp()); | ||
| *dbg!(&temp(), 1).0; | ||
| *dbg!(0, &temp()).1; | ||
| *dbg!(0, &temp(), 2).1; | ||
|
Comment on lines
+9
to
+12
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Only the last couple of these actually regressed, but I figure we may as well be resilient to changes in Also, the dereferences of the temporary aren't necessary to reproduce this and weren't present in the reproducer found by crater, but I feel like being explicit makes the intent of the test clearer. |
||
| } | ||
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.
Why do we need a double reference here? Is it to support some crazy code doing
impl Debug for &Thing?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.
I'm not sure! The double reference just coerces away as part of the cast, right? But it's been that way since #142594, so I figured I'd leave it be.
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.
.. though on second thought, just removing the
&would be a very small PR on its own, so maybe it could be bundled in here, especially if the decision is to backport a revert of #149869 instead of this.Uh oh!
There was an error while loading. Please reload this page.
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.
Huh. This code has compiled ever since the stabilization of
dbg!()in 1.32.0.Removing the double reference would break this code.
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.
That feels probably accidental ^^ but it definitely shouldn't be changed as part of this, then.
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.
The
dbg!macro has always done the equivalent ofprintln!("{:?}", &x). The double reference is necessary to keep those semantics.You can do something like
if you really want to get rid of the double reference/cast, though.