Change:
} else { err.span_help(source_info.span, "try removing `&mut` here"); } <del> } else if decl.mutability == Mutability::Not && !matches!( </del> <ins> } else if decl.mutability == Mutability::Not { if matches!( </ins> decl.local_info, Some(box LocalInfo::User(ClearCrossCrate::Set(BindingForm::ImplicitSelf( hir::ImplicitSelfKind::MutRef <del> )))) ) { err.span_suggestion_verbose( decl.source_info.span.shrink_to_lo(), "consider making the binding mutable", "mut ", Applicability::MachineApplicable, ); </del> <ins> ),))) ) { err.note( "as `Self` may be unsized, this call attempts to take `&mut &mut self`", ); err.note("however, `&mut self` expands to `self: &mut Self`, therefore `self` cannot be borrowed mutably"); } else { err.span_suggestion_verbose( decl.source_info.span.shrink_to_lo(), "consider making the binding mutable", "mut ", Applicability::MachineApplicable, ); }; </ins> } }

Discussion:
I am trying to extend ByteOrder + Seek, and I have two traits, right now. The first is just extending ByteOrder, and the second extends ByteOrder + Seek For some reason, I get this error when compiling, and it only occurs on the line with readbytes. There are two ways I can work around this, for now. One is by copying the method into the other trait, which I don't really wanna do, or I found this goofy code will also work... Hopefully this helps clue you in on what is going on. Is this a bug with the borrow checker? <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
I tried reproducing your issue in and this is the error I got: It doesn't complain about mutability though, but rather about a bound (which is implied in the implementation of but not in the one of . The diagnostic also suggests a way to fix the issue, with other alternatives being adding a supertrait to or a constraint to , although both seem non-ideal.
The underlying issue is . The cleanest solution is changing your blanket impl to , propagating up the bound from and label +A-diagnostics
That does fix it, yea. I only have to add ?Sized to the first trait. Should I add it to all of these traits, or I will encounter this again? I am new to rust, and still not entirely sure what this means, or what it means for my trait. Thanks!

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following : The current output is: <!-- The following is not always necessary. --Ideally the output should look like: add trait bound and the code compiles successfully: rust version: rustc 1.58.0 ( 2022-01-11)
okay..l realized the real reason is that I implies for , so maybe "trait not implied for " is more suitable?
Oh lol, I think this is because of autoref. It's trying to take of self (i.e. grab a pointer) since that means which is , but the argument (i.e. ) is not mutable. Wonder how much work it is to make autoref during method dispatch to skip taking of a method receiver in cases where it's known to fail (e.g. parameter shorthand syntax).
well, I think you are right. It's my thoughtlessness.
I think this is still worthwhile to keep open as an issue because of the confusing error message!
and I'd like to point out how unhelpful the error is: Given that the signature is , it's confusing to say This is the only thing that is said, there is no suggestion You have to figure out it means the is not mutable, vs. the referenced You have to know about method resolution to have a chance of understanding it's trying to create a to call the implementation of You have to know about implicit bounds and where they aren't to have a chance of understanding why it's not calling an implementation of It is a bit tricky though, as there are at least three possible suggestions: Change the signature to Add a bound to Add a bound on the blanket implementation: The last solution is the most correct in my opinion (but can only be applied if that implementation is local). Finally, Does give a suggestion: Even though it's not the ideal suggestion. Let me know if I should file a separate bug for sugar disabling diagnostic suggestions. (If it exists I didn't find it.) label +D-confusing +D-terse +D-newcomer-roadblock