Description
Given the following code:
fn takes_fnonce(f: impl FnOnce(&i32)) { f(&0) }
fn takes_fnmut(f: impl FnMut(i32)) { takes_fnonce(f) }The current output is:
error[E0277]: expected a `FnOnce<(&i32,)>` closure, found `impl FnMut(i32)`
--> src/lib.rs:3:51
|
3 | fn takes_fnmut(f: impl FnMut(i32)) { takes_fnonce(f) }
| ------------ ^ expected an `FnOnce<(&i32,)>` closure, found `impl FnMut(i32)`
| |
| required by a bound introduced by this call
|
note: required by a bound in `takes_fnonce`
--> src/lib.rs:1:25
|
1 | fn takes_fnonce(f: impl FnOnce(&i32)) { f(&0) }
| ^^^^^^^^^^^^ required by this bound in `takes_fnonce`
help: consider further restricting this bound
|
3 | fn takes_fnmut(f: impl FnMut(i32) + for<'r> std::ops::FnOnce<(&'r i32,)>) { takes_fnonce(f) }
| ++++++++++++++++++++++++++++++++++++++
For more information about this error, try `rustc --explain E0277`.
error: could not compile `fn-trait-bad-rendering` due to previous error
Ideally the output should look like:
error[E0277]: expected a `FnOnce<(&i32,)>` closure, found `impl FnMut(i32)`
--> src/lib.rs:3:51
|
3 | fn takes_fnmut(f: impl FnMut(i32)) { takes_fnonce(f) }
| ------------ ^ expected an `FnOnce(&i32)` closure, found `impl FnMut(i32)`
| |
| required by a bound introduced by this call
|
note: required by a bound in `takes_fnonce`
--> src/lib.rs:1:25
|
1 | fn takes_fnonce(f: impl FnOnce(&i32)) { f(&0) }
| ^^^^^^^^^^^^ required by this bound in `takes_fnonce`
help: consider further restricting this bound
|
3 | fn takes_fnmut(f: impl FnMut(i32) + for<'r> FnOnce(&'r i32)) { takes_fnonce(f) }
| +++++++++++++++++++++++++
For more information about this error, try `rustc --explain E0277`.
error: could not compile `fn-trait-bad-rendering` due to previous error
Frankly it would be nice if we could improve the "further restricting this bound" to be something different (as restricting the bound is impossible in this case--something can't be both FnMut(i32) and FnOnce(&i32)), but we should at least render the FnOnce trait syntax right.
rustc --version --verbose:
rustc 1.61.0-nightly (8d60bf427 2022-03-19)
binary: rustc
commit-hash: 8d60bf427a4b055f464122062e76b3ec34d4f8ba
commit-date: 2022-03-19
host: x86_64-unknown-linux-gnu
release: 1.61.0-nightly
LLVM version: 14.0.0
I cannot seem to find any place to start a bisection, so as far as I can tell this behaviour has always been present.
This code is an MCVE of the following less contrived case (using a bit of truncated code, as the exact details of the implementation of this lexer-like structure are not too important), found by @slavfox:
struct Foo;
impl Foo {
fn peek(&self) -> Option<char> { todo!() }
fn advance(&mut self) { todo!() }
fn eat_while(&mut self, predicate: impl FnMut(char) -> bool) -> String {
let mut buf = String::new();
while let Some(ch) = self.peek().filter(predicate) {
buf.push(ch);
self.advance();
}
buf
}
}
I tested this and it does not seem like the ~constness of the trait bounds of Option::filter affect the overall diagnostic rendering.
I may try to fix this in a PR if I can find out why it is occurring.
@rustbot label: +D-newcomer-roadblock +D-papercut