Assert that the first assert! expression is bool

[estebank]

In the desugaring of assert! in 2024 edition, assign the condition expression to a bool biding in order to provide better type errors when passed the wrong thing.

The span will point only at the expression, and not the whole assert! invocation.

error[E0308]: mismatched types
  --> $DIR/issue-14091.rs:2:13
   |
LL |     assert!(1,1);
   |             ^ expected `bool`, found integer

We no longer mention the expression needing to implement the Not trait.

error[E0308]: mismatched types
  --> $DIR/issue-14091-2.rs:15:13
   |
LL |     assert!(x, x);
   |             ^ expected `bool`, found `BytePos`

In <=2021 edition, we still accept any type that implements Not<Output = bool>.

Fix #122159.

[rustbot]

r? @pnkfelix

rustbot has assigned @pnkfelix.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

The Miri subtree was changed

cc @rust-lang/miri

[estebank]

All of these are because now the unnecessary parentheses lint (correctly) triggers on assert!((expr)).

[estebank]

This is the best example of how this is an improvement.

[estebank]

Sigh, clippy shows at least one test where a suggestion causes there to be a condition that isn't a bool but rather a type where Not returns a bool. We can easily continue supporting that by making the desugaring !!cond, but would rather not do that. This happens when it suggest changing assert_eq!(non_bool, true), ending up as assert!(non_bool), which doesn't work with this change .

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[pnkfelix]

Isn't this technically a breaking change for e.g. (playground):

struct Booly(i32);

impl std::ops::Not for Booly {
    type Output = bool;
    fn not(self) -> Self::Output {
        self.0 == 0
    }
}

fn main() {
    assert!(Booly(1), "booly booly!")
}

[pnkfelix]

At the very least, we might need to tie such a change to an edition.

I am not certain whether this decision would be a T-lang matter or a T-libs-api one. I'll nominate for T-lang for now.

(Namely: The question is whether we can start enforcing a rule that the first expression to assert! must be of bool type, which is how the macro is documented, but its current behavior is a little bit more general, as demonstrated in my prior comment)

@rustbot label +I-lang-nominated

[estebank]

@pnkfelix we can keep the current (undocumented) behavior by making the desugaring be

{
    let x: bool = !!condition;
    x
}

instead of what this PR does:

{
    let x: bool = condition;
    x
}

I believe that would still cause errors to complain about Not not being implemented, instead of the more straightforward type error, albeit with a better span. I don't particularly like the idea of keeping the current emergent behavior if there aren't people exploiting it in crates.io.

Edit: an option would be to have an internal marker trait:

use std::ops::Not;
trait CanAssert {}
impl<T: Not<Output = bool>> CanAssert for T {}

fn main() {
    let _ = Box::new(true) as Box<dyn CanAssert>;
    let _ = Box::new(42) as Box<dyn CanAssert>;
}

error[E0271]: type mismatch resolving `<i32 as Not>::Output == bool`
 --> src/main.rs:7:13
  |
7 |     let _ = Box::new(42) as Box<dyn CanAssert>;
  |             ^^^^^^^^^^^^ expected `bool`, found `i32`
  |
note: required for `i32` to implement `CanAssert`
 --> src/main.rs:3:29
  |
3 | impl<T: Not<Output = bool>> CanAssert for T {}
  |             -------------   ^^^^^^^^^     ^
  |             |
  |             unsatisfied trait bound introduced here
  = note: required for the cast from `Box<i32>` to `Box<dyn CanAssert>`

[pnkfelix]

@estebank what about making the expansion edition-dependent? Is there precedent for that?

Then, editions >= 2024 would expand to what you have proposed in the code of this PR, and editions < 2024 could expand to the !!condition variant form that you have discussed in the comments?

[pnkfelix]

what about making the expansion edition-dependent? Is there precedent for that?

(to answer my own question, panic! is one obvious precedent here. So it seems like making it edition-dependent would be one acceptable path; no opinion yet as to which is best...)

[rustbot]

Some changes occurred in coverage tests.

cc @Zalathar

[estebank]

I tried the marker trait approach for <=2021, and it kind of worked, but the diagnostics were actually worse than just doing { let x: bool = !!$expr; x }, which accounts for pretty much everything we currently support, but with better spans and better errors (if typeof($expr) implements <Not<Output = NotBool>, we now produce an appropriate E0308 type error).

[compiler-errors]

Since I don't think it's been acknowledged above, for the record, this breaks the following code:

fn hello(x: &bool) {
  assert!(x);
}

Because &bool: Not<Output = bool>.

[estebank]

@compiler-errors that is indeed the case for 2024 onwards, not for previous editions.

[pnkfelix]

@compiler-errors that is indeed the case for 2024 onwards, not for previous editions.

I think the critical point is whether an edition-dependent expansion is worth breaking that case (of assert!(x) where x: &bool), or if we should do a non-breaking non-edition-dependent expansion using the let x: bool = !!$expr trick across the board...

---

Update: I don't know whether it is worth going through this exercise explicitly, but there is a design space here. E.g. one set of options is:

1. (stable Rust behavior): in all editions, support arbitrary impl Not<Output=bool> for first parameter to assert!;
2. in edition >= 2024, support just Deref<Target=bool> for first parameter to assert! (e.g. by expanding to let x: &bool = &$expr;), or
3. (this PR): in edition >= 2024, support just bool for first parameter to assert!.

(And then there's variations thereof about how to handle editions < 2024, but that's a separate debate IMO.)

[pnkfelix]

(this is waiting for a decision from T-lang and/or T-libs regarding what interface we want to commit to for assert!)

@rustbot label: +S-waiting-on-team -S-waiting-on-review

[scottmcm]

Nominated for libs-api, because for things that are hypothetically macros written in core I'd mostly lean on them.

Personally this makes sense to me.

[m-ou-se]

The hygiene is not sufficient here. This example now breaks:

fn main() {
    type bool = i32;
    assert!(true);
}

error[E0308]: mismatched types
 --> src/main.rs:3:13
  |
3 |     assert!(true);
  |             ^^^^ expected `i32`, found `bool`
  |

[m-ou-se]

It's probably better and easier to just use if <expr> {} else { panic!(..) }, without making any block expressions or local bindings, and without making any changes to the expansion in previous editions.

[m-ou-se]

The !! solution adds more issues: this is now accepted:

use std::ops::Not;

struct A;
struct B;

impl Not for A {
    type Output = B;
    fn not(self) -> B { B }
}

impl Not for B {
    type Output = bool;
    fn not(self) -> bool { true }
}

fn main() {
    assert!(A);
}

[m-ou-se]

We briefly discussed this in the lib-api meeting.

This seems fine, but we thought it is important to consider if this could just be a non-edition change, considering how rare using Not<Output=bool> in assert!() probably is.

However, in the meeting we failed to realize that that includes &bool; I assume that would have changed the outcome. ^^'

Note to self: For the next libs-api meeting, we should look at what Felix wrote here: #122661 (comment)

[m-ou-se]

We discussed this again in the libs-api meeting. We think it's fine if assert!() no longer supports &bool (and other Not<Output=bool> types) in the next edition. It might be worth checking (with crater) if it's possible to get away with that (breaking) change in all editions, but that seems unlikely.

[estebank]

It just dawned on me that changing the macro from expanding to if !cond { then } to if cond {} else { then }, we get the consistent behavior we want in every edition without any "tricks".

[bors]

☔ The latest upstream changes (presumably #125379) made this pull request unmergeable. Please resolve the merge conflicts.

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting and confirmed that we feel this is entirely the scope of @rust-lang/libs-api to determine, not lang.

@pnkfelix wasn't present, and since he nominated it: if you have any objections to that scoping, @pnkfelix, please raise them.

[scottmcm]

(I'm personally happy with the usual "if it could be written on stable, then it's a libs-api question, not lang" here.)

[rust-log-analyzer]

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

   Compiling ui_test v0.26.5
error[E0308]: mismatched types
   --> /cargo/registry/src/index.crates.io-6f17d22bba15001f/ui_test-0.26.5/src/status_emitter.rs:315:37
    |
315 | ...                   assert!(done, "{key} ({sub_key}) not finished");
    |                               ^^^^ expected `bool`, found `&bool`
help: consider dereferencing the borrow
    |
    |
315 |                             assert!(*done, "{key} ({sub_key}) not finished");

   Compiling clippy_config v0.1.84 (/checkout/src/tools/clippy/clippy_config)
For more information about this error, try `rustc --explain E0308`.
error: could not compile `ui_test` (lib) due to 1 previous error