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

std: Change assert_eq!() to use {} instead of {:?} #12626

Merged
merged 1 commit into from Mar 1, 2014

Conversation

alexcrichton
Copy link
Member

Formatting via reflection has been a little questionable for some time now, and
it's a little unfortunate that one of the standard macros will silently use
reflection when you weren't expecting it. This adds small bits of code bloat to
libraries, as well as not always being necessary. In light of this information,
this commit switches assert_eq!() to using {} in the error message instead of
{:?}.

In updating existing code, there were a few error cases that I encountered:

  • It's impossible to define Show for [T, ..N]. I think DST will alleviate this
    because we can define Show for [T].
  • A few types here and there just needed a #[deriving(Show)]
  • Type parameters needed a Show bound, I often moved this to assert!(a == b)
  • Path doesn't implement Show, so assert_eq!() cannot be used on two paths.
    I don't think this is much of a regression though because {:?} on paths looks
    awful (it's a byte array).

Concretely speaking, this shaved 10K off a 656K binary. Not a lot, but sometime
significant for smaller binaries.

Formatting via reflection has been a little questionable for some time now, and
it's a little unfortunate that one of the standard macros will silently use
reflection when you weren't expecting it. This adds small bits of code bloat to
libraries, as well as not always being necessary. In light of this information,
this commit switches assert_eq!() to using {} in the error message instead of
{:?}.

In updating existing code, there were a few error cases that I encountered:

* It's impossible to define Show for [T, ..N]. I think DST will alleviate this
  because we can define Show for [T].
* A few types here and there just needed a #[deriving(Show)]
* Type parameters needed a Show bound, I often moved this to `assert!(a == b)`
* `Path` doesn't implement `Show`, so assert_eq!() cannot be used on two paths.
  I don't think this is much of a regression though because {:?} on paths looks
  awful (it's a byte array).

Concretely speaking, this shaved 10K off a 656K binary. Not a lot, but sometime
significant for smaller binaries.
bors added a commit that referenced this pull request Mar 1, 2014
Formatting via reflection has been a little questionable for some time now, and
it's a little unfortunate that one of the standard macros will silently use
reflection when you weren't expecting it. This adds small bits of code bloat to
libraries, as well as not always being necessary. In light of this information,
this commit switches assert_eq!() to using {} in the error message instead of
{:?}.

In updating existing code, there were a few error cases that I encountered:

* It's impossible to define Show for [T, ..N]. I think DST will alleviate this
  because we can define Show for [T].
* A few types here and there just needed a #[deriving(Show)]
* Type parameters needed a Show bound, I often moved this to `assert!(a == b)`
* `Path` doesn't implement `Show`, so assert_eq!() cannot be used on two paths.
  I don't think this is much of a regression though because {:?} on paths looks
  awful (it's a byte array).

Concretely speaking, this shaved 10K off a 656K binary. Not a lot, but sometime
significant for smaller binaries.
@bors bors closed this Mar 1, 2014
@bors bors merged commit 02882fb into rust-lang:master Mar 1, 2014
@alexcrichton alexcrichton deleted the assert-eq branch March 1, 2014 08:38
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 25, 2022
… r=flodiebold

fix: trailing ':' on empty inactive reasons

## Description
Fixes trailing ':' even when there is no explanation. e.g.
``` sh
code is inactive due to #[cfg] directives:
```
## Issue
Fixes: rust-lang#12615
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 18, 2024
…cation, r=blyxyas

fix incorrect suggestion for `!(a as type >= b)`

fixes rust-lang#12625

The expression  `!(a as type >= b)` got simplified to `a as type < b`, but because of rust's parsing rules that `<` is interpreted as a start of generic arguments for `type`.  This is fixed by recognizing this case and adding extra parens around the left-hand side of the comparison.

changelog: [`nonminimal_bool`]: fix incorrect suggestion for  `!(a as type >= b)`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants