Add custom message parameter to `assert_eq!` #33976

komamitsu · 2016-05-31T06:30:55Z

assert! macro accepts a custom message parameter and it's sometimes useful. But assert_eq! doesn't have it and users need to use assert! instead of assert_eq! when they want to output a custom message even if the assertion just compares two values. This pull request will resolve those cases.

rust-highfive · 2016-05-31T06:31:09Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

GuillaumeGomez · 2016-05-31T07:14:31Z

Nice! Squash your commits please.

komamitsu · 2016-05-31T10:03:21Z

@GuillaumeGomez Thanks. Squashed them.

GuillaumeGomez · 2016-05-31T11:31:25Z

It's good for me but I'd prefer to let someone from @rust-lang/core team to review it as well.

steveklabnik · 2016-05-31T13:23:47Z

Yes, @rust-lang/lang and @rust-lang/libs should probably sign off on something like this.

oli-obk · 2016-05-31T14:55:11Z

related rfc issue: rust-lang/rfcs#1604

komamitsu · 2016-05-31T15:13:59Z

Oops. I should've checked the issue...

ollie27 · 2016-05-31T16:08:42Z

Is there any reason to use:

assert_eq!("b", xs[i], "xs[{}] should be \"b\" but {}", i, xs[i]);

rather than:

assert!("b" == xs[i], "xs[{}] should be \"b\" but {}", i, xs[i]);

?

brson · 2016-05-31T17:06:38Z

@ollie27 Not that I can think of, since the reason assert_eq exists is to provide a better error message.

komamitsu · 2016-05-31T17:20:42Z

@ollie27
This question sounds to be similar to "Is there any reason to use assert_eq!(a, b) rather than assert!(a == b)?"
Just kidding :)

I prefer assert_eq! to just assert! since assert_eq! seems more explicit to me than assert! when I see test codes.

In major unit test libraries (e.g. JUnit in Java, OUnit in OCaml and Test::Unit in Ruby) in other languages, there are assert_equals which support custom message. So, when I noticed that assert_eq! doesn't accept custom message while assert! supports it, I thought it's just lack of feature or something not design decision.

nrc · 2016-06-01T12:55:44Z

+1

komamitsu · 2016-06-06T16:41:34Z

@brson @GuillaumeGomez Well, should I close this PR...?

aturon · 2016-06-06T16:47:23Z

I agree with @brson, it's simplest to just use assert for a custom message, since assert_eq basically exists just to give a better default message.

nikomatsakis · 2016-06-10T00:09:02Z

I think that @brson and @aturon's logic makes sense, but I confess that I have been regularly surprised that assert_eq doesn't accept a custom message -- and rewriting to use assert never occurred to me.

nikomatsakis · 2016-06-10T00:09:41Z

Like @komamitsu, I have mostly used assert_eq because it seemed more declarative (with a nicer message to boot).

nikomatsakis · 2016-06-10T00:10:13Z

Well, maybe another way to put it is that I got in the habit of using assert_eq long ago, and so now I just do it out of habit whenever there is an equality comparison involved.

brson · 2016-06-10T00:22:53Z

@nikomatsakis good point that having the error message reduces the surprise factor

nrc · 2016-06-10T07:21:38Z

to clarify, +1 to the PR itself - while I understand the argument that assert_eq should do its own thing for the error message, I don't see that as the point of the macro - aiui, assert_eq just saves you writing == (and is implicitly self-documenting), so it makes sense to have an optional message in the same way assert has. I must admit, I've never really been a fan of assert_eq at all - perhaps this mental model is why I don't see the benefit.

SimonSapin · 2016-06-10T07:36:04Z

As I wrote in rust-lang/rfcs#1604, I think the panic message given to assert_eq! should be in addition (concatenated) to the default one. If the default one is replaced entirely instead, that’s the same as assert!(a == b, "message").

IMO the point of assert_eq! over assert! is that it prints the two values for you, so you don’t have to. It can be desirable to have that, and also provide more information/context in the panic message.

aturon · 2016-06-10T17:34:17Z

OK, @nikomatsakis makes a convincing case that it's worth adding something here. @SimonSapin's suggestion makes sense for added value.

cc @rust-lang/libs

alexcrichton · 2016-06-10T23:33:51Z

I feel that as-is this may not add too much value as it's shorter even to use assert! and you'd get the same message, but if we were to append the message to the {left} != {right} then it seems reasonable to me.

komamitsu · 2016-06-13T15:12:48Z

Thanks for the feedbacks. I agree to appending a custom message to the default one.

I have two ideas to do that.

macro_rules! assert_eq {
    ($left:expr , $right:expr) => ({
        match (&($left), &($right)) {
            (left_val, right_val) => {
                if !(*left_val == *right_val) {
                    panic!("assertion failed: `(left == right)` \
                           (left: `{:?}`, right: `{:?}`)", left_val, right_val)
                }
            }
        }
    });
    ($left:expr , $right:expr, $msg:expr) => ({
        match (&($left), &($right)) {
            (left_val, right_val) => {
                if !(*left_val == *right_val) {
                    panic!("assertion failed: `(left == right)` \
                            (left: `{:?}`, right: `{:?}`): {}", left_val, right_val, $msg)
                }
            }
        }
    });
    ($left:expr , $right:expr, $fmt:expr, $($arg:tt)*) => ({
        match (&($left), &($right)) {
            (left_val, right_val) => {
                if !(*left_val == *right_val) {
                    panic!(concat!("assertion failed: `(left == right)` \
                                   (left: `{:?}`, right: `{:?}`): ", $fmt),
                           left_val, right_val, $($arg)*)
                }
            }
        }
    });
}

// assert_eq!(1, 2);     >>> assertion failed: `(left == right)` (left: `1`, right: `2`)
// assert_eq!(1, 2, "Type is u32");
//                       >>> assertion failed: `(left == right)` (left: `1`, right: `2`): Type is u32
// assert_eq!(1, 2, "concurrency = {concurrency}, counter = {counter}",
//                   concurrency = c, counter = i);
//                       >>> assertion failed: `(left == right)` (left: `1`, right: `2`): concurrency = 8, counter = 65536

macro_rules! assert_eq {
    ($left:expr , $right:expr) => ({
        match (&($left), &($right)) {
            (left_val, right_val) => {
                if !(*left_val == *right_val) {
                    panic!("assertion failed: `(left == right)` \
                           (left: `{:?}`, right: `{:?}`)", left_val, right_val)
                }
            }
        }
    });
    ($left:expr , $right:expr, $msg:expr) => ({
        match (&($left), &($right)) {
            (left_val, right_val) => {
                if !(*left_val == *right_val) {
                    panic!("assertion failed: `(left == right)` \
                            (left: `{:?}`, right: `{:?}`): {}", left_val, right_val, $msg)
                }
            }
        }
    });
}

// assert_eq!(1, 2);     >>> assertion failed: `(left == right)` (left: `1`, right: `2`)
// assert_eq!(1, 2, "Type is u32"); 
//                       >>> assertion failed: `(left == right)` (left: `1`, right: `2`): Type is u32
// assert_eq!(1, 2, format!("concurrency = {concurrency}, counter = {counter}",
//                             concurrency = c, counter = i));
//                       >>>  assertion failed: `(left == right)` (left: `1`, right: `2`): concurrency = 8, counter = 65536

The first one can format strings by itself, but it's a bit verbose. The implementation of the second one is simpler, but it doesn't support formatting. I'm wondering which one is better...

alexcrichton · 2016-06-16T09:13:46Z

Ah yeah I'd vote for the first where the message itself can have more arguments and such like assert! can

komamitsu · 2016-06-18T15:27:00Z

Updated the PR

alexcrichton · 2016-06-20T18:31:03Z

src/libcore/macros.rs

+            (left_val, right_val) => {
+                if !(*left_val == *right_val) {
+                    panic!("assertion failed: `(left == right)` \
+                           (left: `{:?}`, right: `{:?}`): {}", left_val, right_val, $msg)


It may be worth using concat! here as well to ensure that a $msg which looks like "foo {}" gives an error saying that it expected an argument rather than being accepted

Maybe this was trying to match unreachable! which can also be given a single argument which implements Display and use that. If we don't want that behaviour and only accept valid format strings I think we can use a single extra rule like:

($left:expr , $right:expr, $($arg:tt)*) => ({ match (&($left), &($right)) { (left_val, right_val) => { if !(*left_val == *right_val) { panic!("assertion failed: `(left == right)` \ (left: `{:?}`, right: `{:?}`): {}", left_val, right_val, format_args!($($arg)*)) } } } });

This will also accept things like assert_eq!(1, 2, "{0}", 3) which I think we do want to accept.

(also we definitely don't want to use concat! as we'll just run into #30143 again)

That definition looks good to me!

alexcrichton · 2016-06-21T04:40:57Z

The libs team got a chance to discuss this PR during triage today and the conclusion was to merge. @komamitsu if you want to update with @ollie27's suggestion, I'll r+!

komamitsu · 2016-06-21T06:39:49Z

@ollie27 Thanks. That's what I wanted to do.

@alexcrichton Okay. Updated the PR

alexcrichton · 2016-06-21T14:18:32Z

@bors: r+ 45a63d3

Thanks!

alexcrichton · 2016-06-21T15:48:28Z

@bors: retry force clean

appears... stuck

bors · 2016-06-21T15:48:33Z

💣 Buildbot returned an error: <span>exceptions.KeyError</span>: <span>'auto-linux-32cross-opt'</span>

bors · 2016-06-21T15:49:45Z

⌛ Testing commit 45a63d3 with merge a32aaea...

alexcrichton · 2016-06-21T23:14:30Z

@bors: retry force clean

bots disappeared?

bors · 2016-06-22T08:05:57Z

⌛ Testing commit 45a63d3 with merge 3ee3267...

Add custom message parameter to `assert_eq!` `assert!` macro accepts a custom message parameter and it's sometimes useful. But `assert_eq!` doesn't have it and users need to use `assert!` instead of `assert_eq!` when they want to output a custom message even if the assertion just compares two values. This pull request will resolve those cases.

bors · 2016-06-22T11:21:57Z

komamitsu · 2016-06-22T23:20:12Z

@alexcrichton Thanks!

donaldpipowitch · 2017-02-03T13:40:24Z

Is this mentioned somewhere in the docs? I looked here and thought it would not be possible to append a custom message. I'm glad it is possible.

GuillaumeGomez · 2017-02-03T21:01:09Z

@donaldpipowitch: You must look into the nightly docs: https://doc.rust-lang.org/nightly/std/macro.assert_eq.html

donaldpipowitch · 2017-02-04T10:04:04Z

Okay, Thank you.

rust-highfive assigned brson May 31, 2016

komamitsu force-pushed the assert_eq_with_msg branch from 25efb26 to a460e49 Compare May 31, 2016 08:12

brson added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label May 31, 2016

komamitsu force-pushed the assert_eq_with_msg branch from a460e49 to 7e0aa04 Compare June 18, 2016 14:18

alexcrichton reviewed Jun 20, 2016
View reviewed changes

Add message argument to assert_eq macro

45a63d3

komamitsu force-pushed the assert_eq_with_msg branch from 7e0aa04 to 45a63d3 Compare June 21, 2016 06:14

alexcrichton added the relnotes Marks issues that should be documented in the release notes of the next release. label Jun 21, 2016

bors merged commit 45a63d3 into rust-lang:master Jun 22, 2016

jonas-schievink mentioned this pull request Jul 19, 2016

Accept extra parameters in assert_eq!, pass them to panic! rust-lang/rfcs#1604

Closed

Add custom message parameter to assert_eq! #33976

Add custom message parameter to assert_eq! #33976

Conversation

komamitsu commented May 31, 2016

rust-highfive commented May 31, 2016

GuillaumeGomez commented May 31, 2016

komamitsu commented May 31, 2016

GuillaumeGomez commented May 31, 2016

steveklabnik commented May 31, 2016

oli-obk commented May 31, 2016

komamitsu commented May 31, 2016

ollie27 commented May 31, 2016

brson commented May 31, 2016

komamitsu commented May 31, 2016 • edited Loading

nrc commented Jun 1, 2016

komamitsu commented Jun 6, 2016

aturon commented Jun 6, 2016

nikomatsakis commented Jun 10, 2016

nikomatsakis commented Jun 10, 2016

nikomatsakis commented Jun 10, 2016

brson commented Jun 10, 2016

nrc commented Jun 10, 2016

SimonSapin commented Jun 10, 2016

aturon commented Jun 10, 2016

alexcrichton commented Jun 10, 2016

komamitsu commented Jun 13, 2016 • edited Loading

alexcrichton commented Jun 16, 2016

komamitsu commented Jun 18, 2016

alexcrichton Jun 20, 2016

Choose a reason for hiding this comment

ollie27 Jun 20, 2016

Choose a reason for hiding this comment

alexcrichton Jun 21, 2016

Choose a reason for hiding this comment

alexcrichton commented Jun 21, 2016

komamitsu commented Jun 21, 2016 • edited Loading

alexcrichton commented Jun 21, 2016

alexcrichton commented Jun 21, 2016

bors commented Jun 21, 2016

bors commented Jun 21, 2016

alexcrichton commented Jun 21, 2016

bors commented Jun 22, 2016

bors commented Jun 22, 2016

komamitsu commented Jun 22, 2016

donaldpipowitch commented Feb 3, 2017

GuillaumeGomez commented Feb 3, 2017

donaldpipowitch commented Feb 4, 2017

Add custom message parameter to `assert_eq!` #33976

Add custom message parameter to `assert_eq!` #33976

komamitsu commented May 31, 2016 •

edited

Loading

komamitsu commented Jun 13, 2016 •

edited

Loading

komamitsu commented Jun 21, 2016 •

edited

Loading