rust-analyzer unable to see some types in zbus::fdo

[Veykril]

dbus2/zbus#671

[ChayimFriedman2]

Can't reproduce. Things are working fine to me (I didn't check on the linked commit but on HEAD).

[Veykril]

Looks like I linked a fork by accident

[zeenix]

Can't reproduce. Things are working fine to me (I didn't check on the linked commit but on HEAD).

That actually part of the reproducer: i-e when using zbus prior to 4.0^ it worked fine.

^: Precisely pinpointing the exact commit that introduced this issue would a bit difficult since it'll require a long git bisect session with no automated reproducer combined with API breakages along the way.

[ChayimFriedman2]

That actually part of the reproducer: i-e when using zbus prior to 4.0^ it worked fine.

Prior to, or after? Because I checked on HEAD, which should have the latest updates.

[Veykril]

Would be nice if you could link a revision that exhibits the problem then

[zeenix]

Because I checked on HEAD, which should have the latest updates.

The latest HEAD of the corrected repo link main, or the main on my personal fork that @Veykril first linked by accident? The latter seems stuck on prior to 4.0 so you should not be able to reproduce there but with former you should be able to reproduce.

[zeenix]

Would be nice if you could link a revision that exhibits the problem then

The latest main and also latest crates.io release.

[ChayimFriedman2]

Because I checked on HEAD, which should have the latest updates.

The latest HEAD of the corrected repo link main, or the main on my personal fork that @Veykril first linked by accident? The latter seems stuck on prior to 4.0 so you should not be able to reproduce there but with former you should be able to reproduce.

The HEAD of the correct repo, not the fork.

[zeenix]

Because I checked on HEAD, which should have the latest updates.

The latest HEAD of the corrected repo link main, or the main on my personal fork that @Veykril first linked by accident? The latter seems stuck on prior to 4.0 so you should not be able to reproduce there but with former you should be able to reproduce.

The HEAD of the correct repo, not the fork.

Oh, that's very strange. Just to be sure a recent refactor in zbus didn't end up somehow "fixing" this, I created a new project here and as you can see in the attached screencast, auto-completion doesn't work for the method of the generated DBusProxy type, even though I'm using the latest HEAD as well (the Cargo.toml is visible in the beginning of the video).

Screencast.from.2024-09-18.22-30-52.mp4

[Veykril]

Can reproduce that, funny how we give the completion for DBusProxy but we aren't actually able to resolve it. The #[proxy] attribute fails to expand on the DBus trait for some reason but only when its used in the dependency

[ChayimFriedman2]

Ok, with DBusProxy I can reproduce (but not with the types from the original issue).

[zeenix]

Can reproduce that, funny how we give the completion for DBusProxy but we aren't actually able to resolve it. The #[proxy] attribute fails to expand on the DBus trait for some reason but only when its used in the dependency

Just a shot in the dark but is it possible that proxy macro eating away its input trait (dbus2/zbus#225), causes this somehow? 🤔 Although that's always been the case so it's unlikely.

[ChayimFriedman2]

If it expands to something, rust-analyzer should be able to see that something. It eating its input should not matter.

[ChayimFriedman2]

@rustbot claim

[ChayimFriedman2]

This is probably the same issue as #17630. This also has to do with a module shadowing the macro, and here too if I move the reexport of proxy at the crate root above the module declaration things start working correctly.

The issue is quite subtle: IDE features (e.g. goto def) do work correctly, but name resolving in the DefMap do not.

[ChayimFriedman2]

Update: I managed to minimize the problem:

mod foo {
    macro_rules! x {
        () => {
            pub struct Foo;
        };
    }
    pub(crate) use x as m;
}

mod bar {
    use crate::m;

    m!();

    fn qux() {
        Foo;
    }
}

mod m {}

use foo::m;

Foo in qux() is not resolved, because m!() is not expanded, because:

a. In the same scope of m (crate), there is also a module with the same name.
b. m!() is imported after its use (in bar). Specifically, it's the place of m!() relative to its usage that matters, not relative to the m module.

[ChayimFriedman2]

Ok, I nailed the problem, and I have a fix, but I need to check because it may prove too expensive...

[zeenix]

Awesome! Thanks so much @ChayimFriedman2 and @Veykril. 👍🙏