-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.Blocker: Approved by a merged RFC but not yet implemented.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: 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.Relevant to the library API team, which will review and decide on the PR/issue.
Description
This is a tracking issue for the RFC "More readable assert_eq" (rust-lang/rfcs#1866).
Steps:
- Implement the RFC (assert_eq failure message easier to read #42541)Adjust documentation (see instructions on forge)Stabilization PR (see instructions on forge)To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Unresolved questions:
- Should we also cover
assert_ne
? - Should we incorporate color support, or use LLVM-style arrows?
Metadata
Metadata
Assignees
Labels
B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.Blocker: Approved by a merged RFC but not yet implemented.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: 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.Relevant to the library API team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
colin-kiegel commentedon Apr 29, 2017
assert_ne
should also print multi-lines, but not show a diffassert_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:golddranks commentedon Apr 29, 2017
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 commentedon Apr 29, 2017
git diff --word-diff
does the following by defaultWhere
[-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 commentedon Dec 26, 2017
Is this tracking issue supposed to be closed?
kennytm commentedon Dec 26, 2017
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.
jonas-schievink commentedon Nov 26, 2019
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 commentedon Jan 31, 2020
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.
Auto merge of #42541 - gilescope:patch-1, r=alexcrichton