Tracking issue for RFC 2011: Generic assert

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 ↩

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.

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.

@ishitatsuyuki

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?

@sinkuu

@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.

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

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.

@gilescope

@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)

Auto merge of rust-lang#111928 - c410-f3r:dqewdas, r=eholk

Auto merge of rust-lang#134126 - c410-f3r:hocus-pocus, r=<try>

Rollup merge of rust-lang#135139 - c410-f3r:8-years-rfc, r=jhpratt

Unrolled build for rust-lang#135139

@c410-f3r

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.

@c410-f3r IIUC the most straightforward implementation (where you write const and ~const in a few places and rustc does the rest) requires dynamic dispatch in CTFE, which in turn requires const fn() function pointers. This is because Formatter internally holds and writes to a dyn fmt::Write.

Here's a little const formatting demo i threw together a couple months ago: https://gist.github.com/Sky9x/e11cb7ba0772289c05172ebda7dcaeda
the code is pretty crap but it all leads to this line:

const MEOW: &str = const_format!("meow", " :3 ", -59999, ' ', true, ' ', 'x', '3');

where MEOW is a &'static str and after const evaluation it has the content "meow :3 -59999 true x3".

I couldn't be bothered to implement template parsing so instead it just formats and concatenates everything into one big buffer, then returns it as a &'static str. The macro will also panic if called at runtime.

However, that API is not suitable for use in std because it makes Formatter and Display::fmt generic over the writer type, which is a breaking change.

The intention is to "constify" all methods and related traits of https://github.com/rust-lang/rust/blob/master/library/core/src/asserting.rs, which is on the library side.

If additional support is necessary on the compiler side beyond the ongoing #[const_trait] effort, then it is probably wise to just skip generic_assert in constant environments.

Rollup merge of rust-lang#135139 - c410-f3r:8-years-rfc, r=jhpratt

Navigation Menu

Repository navigation

Tracking issue for RFC 2011: Generic assert #44838

About tracking issues

Steps

Blockers

Implementation history

35 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for RFC 2011: Generic assert #44838

Description

About tracking issues

Steps

Blockers

Implementation history

Footnotes

Activity

bstrie commented on Sep 27, 2017

durka commented on Sep 27, 2017

bstrie commented on Sep 27, 2017

emilio commented on Feb 7, 2018

ishitatsuyuki commented on Feb 7, 2018

sinkuu commented on Mar 8, 2018

ishitatsuyuki commented on Mar 8, 2018

shepmaster commented on Mar 8, 2018

gilescope commented on Mar 21, 2018

ishitatsuyuki commented on Mar 21, 2018

35 remaining items

Sky9x commented on Feb 23, 2025

c410-f3r commented on Feb 24, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions