Rust-analyser shows argument names like `_x0`, `_x1` once mocked with Faux

[nickdecooman]

Hello,

I experience that when a struct is mocked with Faux, Rust-analyzer shows the argument names of the struct's method like _x0, _x1 etc.

Obviously, this is not a major issue, just wondering whether this is a common issue. Also, not sure if this is caused by Faux or by Rust-analyzer itself.

Let me give an example to make my point more clear:

#[cfg_attr(any(test, feature = "faux"), faux::create)]
pub struct Client {
    pub n: u8,
}

#[cfg_attr(any(test, feature = "faux"), faux::methods)]
impl Client {
    pub fn new() -> Self {
        return Client { n: 5 };
    }

    pub fn set_n(&mut self, n: u8, a: u8) {
        self.n = n;
    }
}

struct Foo {}

impl Foo {
    pub fn new() -> Foo {
        let mut client = Client::new();
        client.set_n(5, 5);
        return Foo {};
    }
}

In this case, Rust-analyzer (in VSCode) shows the following:

Note that I am not even using Client::faux() but just Client::new()

When I remove the faux mocking around Client, it shows again n and a argument names.

[nrxus]

The issue is three-fold:

• rust-analyzer does its magic using the test cfg (presumably so it can also give hints/warnings on tests?). If this wasn't true it would show just right since faux is only active during tests.

• rust-analyzer does all its hint overlays using the post-macro expansion code. This is probably because macros are allowed to change the signature completely so it wouldn't be correct for those kind of macros otherwise. faux effectively only changes the body so if rust-analyzer did its hint overlay with pre-expansion code then it would be better for us.

• faux changes the name of the variables because arguments in rust functions accept patterns not just identifiers( e.g.,fn foo(&self, (a,b): (i32, i32)) {}) but faux just wants the entire argument not the pattern so it just puts an identifier there to capture the entire variable regardeless of the pattern.

Asking rust-analyzer to change its behavior is probably a non starter as what they are doing is logical just unfortunate for faux. I had never run into this because I don't use overlay hints but I know I am probably in the minority there 😅 .

The culprit in faux is: https://github.com/nrxus/faux/blob/a3538b7649909a23c7afed64c360644ac72031ac/faux_macros/src/methods/morphed.rs#L130-L138

I think for the easy case where the pattern is just a single identifier (foo: Foo) we can probably use the identifier instead of the "normalized" name (_x{i}) but keep the hack in there for the weird patterns. If you want to dig into the wild world of macros you can try taking a stab at it, otherwise I'll probably take a look next week 😄

[nickdecooman]

Hey @nrxus, thanks for getting back so quickly and providing this context! 🙌

I think fixing the easy case would be a huge step forward, and definitely in my case fix all the overlays.

Happy to help you test a potential fix! ✌️

[nrxus]

Hey @nickdecooman, I just pushed a commit up on master that I think should take care of this. Life and work got busier than usual so it took longer than expected 😅 .

If you want you can try to use faux from master and let me know how that works out for you. If it all works as expected for you I'll do a release soon after.

[nickdecooman]

Thank you so much @nrxus ! 🙌

I tried the master branch and it works like a charm! The arguments now correctly show up in Rust-analyser as expected 🤩

[nrxus]

I have published a new version (v0.1.7) with the fix included. Thanks for submitting the issue!