fix: show no error when parameters match macro names

[Aditya-PS-05]

closes #21070

Parameter names are bindings, not references, thus should not be qualified.

Previously, when implementing trait members, parameter names that matched macro names (e.g., vec, format, panic) were incorrectly qualified as std::vec, std::format, etc.

The issue was in transform_ident_pat() which was too aggressive - it qualified all identifier patterns that resolved to definitions, including macros.

Added a test also to test this functionality,

[fennewald]

This looks great, thank you for implementing something so quickly!

It's worth noting that even if I remove your fixes, the test you added still passes. I spent a few hours trying to dream up a test that could cover this, and was unable to make headway.

Adding minicore: panic does not help trigger the behavior. I also tried re-creating the std scheme directly, using something like:

//- /lib.rs crate:alloc
#[macro_use]
mod macros {
    #[macro_export]
    macro_rules! vec {
        () => {};
    }
}

//- /lib.rs crate:std deps:alloc extern-prelude:alloc
#[allow(unused_imports)]
#[macro_use]
extern crate alloc as alloc_crate;
pub use alloc_crate::vec;

// minicore: panic
//- /main.rs crate:bin deps:std extern-prelude:std
#[prelude_import]
pub use std::*;

trait Foo {
    fn foo(&self, vec: usize);
}

struct Bar;

impl Foo for Bar$0 {}

However, I was also unable to find a form of this that worked. I experimented with adding vec to minicore directly, but was again unsuccessful.

It may be moot, though, I believe that your fix does resolve the issue at hand.

[fennewald]

Lovely.

I can confirm on my machine that the test accurately fails without your fix, and passes with it!

[ChayimFriedman2]

I don't think we should be treating parameters specifically, when local variables suffer from the same problem.

The real question is why we're resolving them to the macro and not the local variable, which will work automatically.

[Aditya-PS-05]

I don't think we should be treating parameters specifically, when local variables suffer from the same problem.

The real question is why we're resolving them to the macro and not the local variable, which will work automatically.

done

[ChayimFriedman2]

This isn't perfect, I would prefer to fix the resolution to resolve to the variable, but it's better than nothing.

Thanks!