Skip to content

Tracking issue for RFC 1866: More readable assert_eq #41615

@aturon

Description

@aturon
Member

This is a tracking issue for the RFC "More readable assert_eq" (rust-lang/rfcs#1866).

Steps:

Unresolved questions:

  • Should we also cover assert_ne?
  • Should we incorporate color support, or use LLVM-style arrows?

Activity

added
B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.
T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.
on Apr 29, 2017
colin-kiegel

colin-kiegel commented on Apr 29, 2017

@colin-kiegel
  • IMO assert_ne should also print multi-lines, but not show a diff
  • Color support in the built-in assert_eq! would be awesome. :-)

small side-note: In case anyone wants to use this before it is stabilized, I just implemented multiline display in pretty_assertions (v0.2) and it currently looks like this:

pretty assertion

golddranks

golddranks commented on Apr 29, 2017

@golddranks
Contributor

Btw. red and green aren't maybe the best choices for colour coding, as the red-green colour blindness is the most common type of vision deficiency out there. (The coloured pieces would still stand out from the normal text if I understand red-green-colour blindness correctly, but not from each others.)

colin-kiegel

colin-kiegel commented on Apr 29, 2017

@colin-kiegel

git diff --word-diff does the following by default

The quick brown [-duck-]{+fox+} jumps over the lazy dog

Where [-duck-] and {+fox+} are colored red/green if the terminal supports it. This is also readable without color support (or color blindness). However this might be ambiguous if the underlying text already contains such character sequences.

ordovicia

ordovicia commented on Dec 26, 2017

@ordovicia
Contributor

Is this tracking issue supposed to be closed?

kennytm

kennytm commented on Dec 26, 2017

@kennytm
Member

Thanks @ordovicia.

I've reopened the issue since there are still two unresolved questions (color and arrow).

However AFAIK there can be no "Stabilization PR", the change is insta-stable. For "Adjust documentation", perhaps check the books if the output format needs to be updated, but otherwise no specific documentation is needed for this feature.

added
C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
on Jan 22, 2018
jonas-schievink

jonas-schievink commented on Nov 26, 2019

@jonas-schievink
Contributor

Implement the RFC (#42541)

That does not look like the complete implementation. If it is, then this issue can probably be closed since this has been the stable output since over 2 years now.

jonas-schievink

jonas-schievink commented on Jan 31, 2020

@jonas-schievink
Contributor

I just re-read the RFC and this is indeed fully implemented. I do not think there's anything left to document/stabilize, and there's also #44838 tracking further improvements to assertion error messages, so closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @kennytm@aturon@jonas-schievink@golddranks@XAMPPRocky

        Issue actions

          Tracking issue for RFC 1866: More readable assert_eq · Issue #41615 · rust-lang/rust