Skip to content

inconsistent and confusing error message about first argument of assert! #122159

@jendrikw

Description

@jendrikw

Code

fn f(x: Result<i8, Box<dyn std::error::Error>>) { assert!(x.unwrap(), "expected Ok"); // expected `bool`, found `i8` assert!(x.unwrap_err(), "expected Err"); // cannot apply unary operator `!` }

Current output

error[E0308]: mismatched types --> src/lib.rs:2:5 | 2 | assert!(x.unwrap(), "expected Ok"); // expected `bool`, found `i8` | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `bool`, found `i8` error[E0600]: cannot apply unary operator `!` to type `Box<dyn std::error::Error>` --> src/lib.rs:3:5 | 3 | assert!(x.unwrap_err(), "expected Err"); // cannot apply unary operator `!` to type `Box<dyn std::error::Error>` | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot apply unary operator `!` | = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info) Some errors have detailed explanations: E0308, E0600. For more information about an error, try `rustc --explain E0308`.

Desired output

No response

Rationale and extra context

The macro assert! is documented as taking a bool as its first parameter. Therefore I suggest the error message be expected `bool`, found `i8` in both cases.

The very different error messages are very confusing, because Result::unwrap and Result::unwrap_err are basically the same. While I understand both error messages, I do not understand why they are different.

Edit: I just realized it's probably because i8 has an implementation of std::ops::Not. Still weird.

Other cases

No response

Rust Version

rustc 1.76.0 (07dca489a 2024-02-04) binary: rustc commit-hash: 07dca489ac2d933c78d3c5158e3f43beefeb02ce commit-date: 2024-02-04 host: x86_64-unknown-linux-gnu release: 1.76.0 LLVM version: 17.0.6

Anything else?

No response

Metadata

Metadata

Assignees

Labels

A-diagnosticsArea: Messages for errors, warnings, and lintsD-confusingDiagnostics: Confusing error or lint that should be reworked.T-compilerRelevant to the compiler 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

Issue actions