-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Closed
Labels
A-macromacro expansionmacro expansionA-nameresname, path and module resolutionname, path and module resolutionC-bugCategory: bugCategory: bug
Description
rust-analyzer version: v0.4.1299
rustc version: 1.65.0
MRE
To reproduce the problem, create a new crate (I'll call it my_crate for the sake of this example) with a main.rs and a lib.rs.
The lib.rs:
// lib.rs
/// Some crazy documentation
#[macro_export]
macro_rules! column {
() => {
"hello"
};
}The main.rs
// main.rs
use my_crate::column; // <-- This macro's name clashes with `core::macros::builtin::column`
fn main() {
// R-A resolves this as the `core::macros::builtin::column` macro (which returns a u32),
// so it thinks something is wrong with this code.
// rustc is able to compile this just fine (i.e. it resolves our own `column` macro correctly)
let _ = column!().chars();
}What I expected to happen
I expected R-A to analyze understand that our macro shadows the built-in one. This is the correct Rust behavior.
Aliasing our macro import with as solves the problem, but should not be required.
What actually happens
R-A complains about {unknown} methods, and when the macro call is hovered, it offers the documentation for the bult-in macro instead of our own macro.
And yet, the code compiles just fine, because it is completely valid.
d4h0 and ModProg
Metadata
Metadata
Assignees
Labels
A-macromacro expansionmacro expansionA-nameresname, path and module resolutionname, path and module resolutionC-bugCategory: bugCategory: bug


