Tracking issue for RFC 2011: Generic assert #44838

alexcrichton · 2017-09-25T14:14:57Z

This is a tracking issue for rust-lang/rfcs#2011.
The feature gate for the issue is #![feature(generic_assert)].

Sub tracking-issue: #96949.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Implementation (see section Implementation history)
Final comment period (FCP)¹
Stabilization PR

Blockers

Does not work in const eval yet.

Implementation history

https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

The text was updated successfully, but these errors were encountered:

emilio · 2018-02-07T12:35:37Z

Quick question, is it expected for this to have some sort of switch to less-nice error messages? Sometimes people care about code size, and including a bunch of debug formatters on release builds may not be acceptable.

ishitatsuyuki · 2018-02-07T12:48:02Z

This was one of the concerns in the RFC, and following are some points:

The performance impact may be minimal, as the first step is just making assert having assert_eq's functionality.
If notable regression was found, we may decide to disable some of the rules for release builds.
For certain critical path, debug assertions or custom formatters may be used to minimize (control) the performance impact, just as before.

sinkuu · 2018-03-08T04:05:34Z

I am trying to implement this, but have not been successful so far. The problem is that we don't know if a operand is Copy during macro expansion.

Status quo(sinkuu@ba00a0e):

assert!(a == b && c)

expands to

let mut __capture0 = None;
let mut __capture1 = None;
let mut __capture2 = None;
// `try_copy` copies it if it implements `Copy`
if !({ let __tmp = a; __capture0 = __tmp.try_copy(); __tmp }
   == { let __tmp = b; __capture1 = __tmp.try_copy(); __tmp }
   && { let __tmp = c; __capture2 = __tmp.try_copy(); __tmp }) {
    panic!("assertion failed: a == b && c\nwith expansion: {:?} == {:?} && {:?}", ...);
}

But this moves non-Copy operands into assert, and causes use-after-move afterward.

@ishitatsuyuki Do you have concrete implementation strategies in mind?

ishitatsuyuki · 2018-03-08T04:34:40Z

@sinkuu Nice work! However, PartialEq takes self by reference, which means you don't have to copy/clone it. In this case, we may have to call the trait methods directly instead of the operators.

In the case of moving Ops like Add, your approach is good and should just work.

Another thing is that we should use our own enum instead of Option here, as we need to handle the case of non-Copy type and the case of short-circuit differently.

shepmaster · 2018-03-08T13:47:43Z

You might be able to use the tricks that assert_eq! uses to take references to the arguments as well.

Make `assert` a built-in procedural macro Makes `assert` macro a built-in one without touching its functionality. This is a prerequisite for RFC 2011 (#44838).

gilescope · 2018-03-21T15:57:31Z

I’m probably not meant to comment now given the RFC has been merged, but spare a thought for if it’s possible to line up both sides of an == vertically above and below one another as that can make things much easier to spot the difference. Really love this rfc btw, looking forward to it.

ishitatsuyuki · 2018-03-21T16:03:13Z

@gilescope You're welcome to comment on how we should form the message. The RFC is just meant to be a brief proposal, and there are libraries in other languages that has much more helpful expansion outputs. (Example: https://github.com/power-assert-js/power-assert)

c410-f3r · 2022-05-20T18:25:08Z

Implementation is waiting for review -> #96496

[RFC 2011] Minimal initial implementation Tracking issue: rust-lang#44838 Third step of rust-lang#96496 Implementation has ~290 LOC with the bare minimum to be in a functional state. Currently only searches for binary operations to mimic what `assert_eq!` and `assert_ne!` already do. r? `@oli-obk`

[RFC 2011] Minimal initial implementation Tracking issue: rust-lang#44838 Third step of rust-lang#96496 Implementation has ~290 LOC with the bare minimum to be in a functional state. Currently only searches for binary operations to mimic what `assert_eq!` and `assert_ne!` already do. r? ``@oli-obk``

[RFC 2011] Minimal initial implementation Tracking issue: rust-lang#44838 Third step of rust-lang#96496 Implementation has ~290 LOC with the bare minimum to be in a functional state. Currently only searches for binary operations to mimic what `assert_eq!` and `assert_ne!` already do. r? `@oli-obk`

[RFC 2011] Expand expressions where possible Tracking issue: rust-lang#44838 Fourth step of rust-lang#96496 Extends rust-lang#97665 considering expressions that are good candidates for expansion. r? `@oli-obk`

[RFC 2011] Optimize non-consuming operators Tracking issue: rust-lang#44838 Fifth step of rust-lang#96496 The most non-invasive approach that will probably have very little to no performance impact. ## Current behaviour Captures are handled "on-the-fly", i.e., they are performed in the same place expressions are located. ```rust // `let a = 1; let b = 2; assert!(a > 1 && b < 100);` if !( { ***try capture `a` and then return `a`*** } > 1 && { ***try capture `b` and then return `b`*** } < 100 ) { panic!( ... ); } ``` As such, some overhead is likely to occur (Specially with very large chains of conditions). ## New behaviour for non-consuming operators When an operator is known to not take `self`, then it is possible to capture variables **AFTER** the condition. ```rust // `let a = 1; let b = 2; assert!(a > 1 && b < 100);` if !( a > 1 && b < 100 ) { { ***try capture `a`*** } { ***try capture `b`*** } panic!( ... ); } ``` So the possible impact on the runtime execution time will be diminished. r? `@oli-obk`

[RFC 2011] Optimize non-consuming operators Tracking issue: rust-lang#44838 Fifth step of rust-lang#96496 The most non-invasive approach that will probably have very little to no performance impact. ## Current behaviour Captures are handled "on-the-fly", i.e., they are performed in the same place expressions are located. ```rust // `let a = 1; let b = 2; assert!(a > 1 && b < 100);` if !( { ***try capture `a` and then return `a`*** } > 1 && { ***try capture `b` and then return `b`*** } < 100 ) { panic!( ... ); } ``` As such, some overhead is likely to occur (Specially with very large chains of conditions). ## New behaviour for non-consuming operators When an operator is known to not take `self`, then it is possible to capture variables **AFTER** the condition. ```rust // `let a = 1; let b = 2; assert!(a > 1 && b < 100);` if !( a > 1 && b < 100 ) { { ***try capture `a`*** } { ***try capture `b`*** } panic!( ... ); } ``` So the possible impact on the runtime execution time will be diminished. r? ``@oli-obk``

[RFC 2011] Optimize non-consuming operators Tracking issue: rust-lang#44838 Fifth step of rust-lang#96496 The most non-invasive approach that will probably have very little to no performance impact. ## Current behaviour Captures are handled "on-the-fly", i.e., they are performed in the same place expressions are located. ```rust // `let a = 1; let b = 2; assert!(a > 1 && b < 100);` if !( { ***try capture `a` and then return `a`*** } > 1 && { ***try capture `b` and then return `b`*** } < 100 ) { panic!( ... ); } ``` As such, some overhead is likely to occur (Specially with very large chains of conditions). ## New behaviour for non-consuming operators When an operator is known to not take `self`, then it is possible to capture variables **AFTER** the condition. ```rust // `let a = 1; let b = 2; assert!(a > 1 && b < 100);` if !( a > 1 && b < 100 ) { { ***try capture `a`*** } { ***try capture `b`*** } panic!( ... ); } ``` So the possible impact on the runtime execution time will be diminished. r? ```@oli-obk```

[RFC 2011] Optimize non-consuming operators Tracking issue: rust-lang#44838 Fifth step of rust-lang#96496 The most non-invasive approach that will probably have very little to no performance impact. ## Current behaviour Captures are handled "on-the-fly", i.e., they are performed in the same place expressions are located. ```rust // `let a = 1; let b = 2; assert!(a > 1 && b < 100);` if !( { ***try capture `a` and then return `a`*** } > 1 && { ***try capture `b` and then return `b`*** } < 100 ) { panic!( ... ); } ``` As such, some overhead is likely to occur (Specially with very large chains of conditions). ## New behaviour for non-consuming operators When an operator is known to not take `self`, then it is possible to capture variables **AFTER** the condition. ```rust // `let a = 1; let b = 2; assert!(a > 1 && b < 100);` if !( a > 1 && b < 100 ) { { ***try capture `a`*** } { ***try capture `b`*** } panic!( ... ); } ``` So the possible impact on the runtime execution time will be diminished. r? ````@oli-obk````

c410-f3r · 2022-10-31T11:43:07Z

The only thing blocking progress is the lack of formatting in constant environments, i.e., things like const _: () = { panic!("{}", 1i32); }; don't work. This current limitation is something that I will try to figure out after enabling the capture of variables in matches! declarations.

Hope to come back here with good news in the next few months.

[RFC-2011] Expand more expressions cc rust-lang#44838 Expands `if`, `let`, `match` and also makes `generic_assert_internals` an allowed feature when using `assert!`. `#![feature(generic_assert)]` is still needed to activate everything. ```rust #![feature(generic_assert)] fn fun(a: Option<i32>, b: Option<i32>, c: Option<i32>) { assert!( if a.is_some() { 1 } else { 2 } == 3 && if let Some(elem) = b { elem == 4 } else { false } && match c { Some(_) => true, None => false } ); } fn main() { fun(Some(1), None, Some(2)); } // Assertion failed: assert!( // if a.is_some() { 1 } else { 2 } == 3 // && if let Some(elem) = b { elem == 4 } else { false } // && match c { Some(_) => true, None => false } // ); // // With captures: // a = Some(1) // b = None // c = Some(2) ```

alexcrichton added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Sep 25, 2017

alexcrichton mentioned this issue Sep 25, 2017

Add generic_assert rust-lang/rfcs#2011

Merged

TimNN added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Sep 27, 2017

This comment has been minimized.

Sign in to view

sinkuu mentioned this issue Mar 7, 2018

Make assert a built-in procedural macro #48813

Merged

sinkuu mentioned this issue Mar 13, 2018

Implement RFC 2011 (nicer assert messages) #48973

Closed

kennytm mentioned this issue May 30, 2018

assert_eq!(a,b) fails to compile for slices while assert!(a == b) works fine #51206

Open

petrochenkov mentioned this issue Oct 17, 2018

Cleanup resolve #55144

Merged

petrochenkov mentioned this issue Apr 17, 2019

Make assert! ensure the macro is parsed completely #60039

Merged

jonas-schievink mentioned this issue Jan 31, 2020

Tracking issue for RFC 1866: More readable assert_eq #41615

Closed

3 tasks

KodrAus added A-fmt Area: `std::fmt` Libs-Tracked Libs issues that are tracked on the team's project board. A-error-handling Area: Error handling labels Jul 31, 2020

KodrAus mentioned this issue Sep 29, 2020

Error Handling Project Group rust-lang/libs-team#3

Open

de-vri-es mentioned this issue Nov 12, 2020

Pretty print assertion failures in tests #79001

Closed

ndmitchell mentioned this issue Jan 25, 2021

Reeneable should_assert_eq lint rust-lang/rust-clippy#6637

Open

c410-f3r mentioned this issue Apr 28, 2022

Implement RFC-2011 (Nicer assert! messages) #96496

Closed

c410-f3r mentioned this issue Jun 3, 2022

[RFC 2011] Minimal initial implementation #97665

Merged

c410-f3r mentioned this issue Jun 15, 2022

[RFC 2011] Expand expressions where possible #98148

Merged

c410-f3r mentioned this issue Jun 21, 2022

[RFC 2011] Optimize non-consuming operators #98337

Merged

c410-f3r mentioned this issue Apr 16, 2023

[RFC-2011] Expand matches! #110382

Closed

c410-f3r mentioned this issue May 25, 2023

[RFC-2011] Expand more expressions #111928

Merged

epage mentioned this issue Dec 4, 2023

Improved assertions rust-lang/libtest-next#57

Open

nicklimmm mentioned this issue Jan 9, 2024

assert! on == should be assert_eq! rust-lang/rust-clippy#12112

Closed

fmease added the F-generic_assert `#![feature(generic_assert)]` label Apr 8, 2024

fmease mentioned this issue Apr 8, 2024

Tracking issue for the implementation of RFC 2011: Generic assert #96949

Open

6 tasks

fmease added the S-tracking-impl-incomplete Status: The implementation is incomplete. label Apr 8, 2024

fmease changed the title ~~Tracking issue for RFC 2011: nicer assert messages~~ Tracking issue for RFC 2011: Generic assert Oct 16, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for RFC 2011: Generic assert #44838

Tracking issue for RFC 2011: Generic assert #44838

alexcrichton commented Sep 25, 2017 •

edited by fmease

Loading

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

emilio commented Feb 7, 2018

ishitatsuyuki commented Feb 7, 2018

sinkuu commented Mar 8, 2018

ishitatsuyuki commented Mar 8, 2018

shepmaster commented Mar 8, 2018

gilescope commented Mar 21, 2018

ishitatsuyuki commented Mar 21, 2018

c410-f3r commented May 20, 2022

c410-f3r commented Oct 31, 2022

Tracking issue for RFC 2011: Generic assert #44838

Tracking issue for RFC 2011: Generic assert #44838

Comments

alexcrichton commented Sep 25, 2017 • edited by fmease Loading

About tracking issues

Steps

Blockers

Implementation history

Footnotes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

emilio commented Feb 7, 2018

ishitatsuyuki commented Feb 7, 2018

sinkuu commented Mar 8, 2018

ishitatsuyuki commented Mar 8, 2018

shepmaster commented Mar 8, 2018

gilescope commented Mar 21, 2018

ishitatsuyuki commented Mar 21, 2018

c410-f3r commented May 20, 2022

c410-f3r commented Oct 31, 2022

alexcrichton commented Sep 25, 2017 •

edited by fmease

Loading