Idiomatic Rc::clone is unusable with dyn Trait parameters

[neyo8826]

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0771a25efd95be83580de70b3d08db75

AFAIK Rc::clone() should be used, instead of .clone().
It seems free functions are getting their type parameters from the outer scope, not from their own arguments.
Can we coerce it somehow

[jonas-schievink]

Isn't this just caused by the fact that .-syntax performs coercions on the receiver?

[neyo8826]

fn clone(&self) -> Self;
fn clone(&self) -> Rc<T>;

So, the UFCS version gets it actual type from the caller site (Rc<T>).
The coercion shoud occour after the function call, since the type of self is fix, not the coerced result.
We could restrict this deduction inversion for cases invovin subtyping only (T as dyn Trait)

[kennytm]

This is rust-lang/rust-clippy#2048 which is also one of the reasons why the clippy::clone_on_ref_ptr lint has been demoted to the "restriction" group. That is, we no longer consider in general Rc::clone(&st) is more idiomatic than st.clone().

The workaround is to write Rc::<St>::clone(&st), BTW.