Using std::borrow::Borrow has sneaky consequences

[joIivier]

Consider the following playground that compiles fine:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d735c0950cb1b25e8ff19e6a5c9d0445

use std::sync::Mutex;
use std::cell::RefCell;
//use std::borrow::Borrow;

struct A {
    child: Mutex<RefCell<i32>>,
}

impl A {
    fn is_good(&self) -> bool {
        let cell = self.child.lock().unwrap();
        let opt_target = cell.borrow();
        *opt_target > 1
    }
}

Uncommenting the use std::borrow::Borrow; breaks it quite badly:

error[E0369]: binary operation `>` cannot be applied to type `std::sync::MutexGuard<'_, std::cell::RefCell<i32>>`
  --> src/lib.rs:13:21
   |
13 |         *opt_target > 1
   |         ----------- ^ - {integer}
   |         |
   |         std::sync::MutexGuard<'_, std::cell::RefCell<i32>>
   |
   = note: an implementation of `std::cmp::PartialOrd` might be missing for `std::sync::MutexGuard<'_, std::cell::RefCell<i32>>`

This problem does not appear when there is no RefCell inside the Mutex.
This creates confusion when the same function works in a module and not in another.
Especially when Borrow is not implemented directly by Mutex or MutexGuard it is quite hard to understand what happens here, I guess it is due to a blanket implementation since RefCell<i32> is Sized.

My main issue in this situation is that I spent a lot of time facing this compilation issue in a module whereas the same kind of code worked in multiple other modules. I had to comment/remove every other struct/impls/use in the module until I found the culprit.
Maybe the error message could be improved to hint at traits in scope that could alter the expected behavior ?

The issue appeared on stable and nightly (rustc 1.41.0-nightly (53712f8 2019-11-21)).

[joIivier]

On a side note, in my situation this was triggered by the IntelliJ rust plugin that added the use std::borrow::Borrow automatically in some situation to help me, which had clearly the opposite effect.

[Veykril]

To my understanding the snippet without the std::borrow::Borrow should compile, since the borrow call there is the borrow method of std::cell::RefCell which is being accessed through the deref of the MutexGuard.

[csmoe]

To my understanding the snippet without the std::borrow::Borrow should compile, since the borrow call there is the borrow method of std::cell::RefCell.

yep, my bad. borrow came from RefCell's inherent method.