expand glob import should expand to all possible items without filtering for pub use reexports.

[vi]

rust-analyzer version: 0.4.1255-standalone
rustc version: rustc 1.66.0-nightly (3f83906b3 2022-09-24)

mod qqq {
    use super::*;

    pub trait Tr1{}
    pub trait Tr2{}
    pub struct St1{}
    pub struct St2{}
    pub enum En1{}
}

pub use qqq::┃*;

After "expand glob import", I expect.

mod qqq {
    use super::*;

    pub trait Tr1{}
    pub trait Tr2{}
    pub struct St1{}
    pub struct St2{}
    pub enum En1{}
}

pub use qqq::┃{Tr1, Tr2, St1, St2, En1};

but I get:

mod qqq {
    use super::*;

    pub trait Tr1{}
    pub trait Tr2{}
    pub struct St1{}
    pub struct St2{}
    pub enum En1{}
}

pub use qqq::┃{};

Unless RA is willing to analyse the whole workspace for which reexports are actually needed, I think it should just expand to everything. This would allow for easy gradual refactor by moving chunks of code to separate files without also having multiple glob imports one after another.

Alternatively, a second, simpler code assist "Expand glob import (all items)" can be added.

Workaround: Use Ctrl+Space, Enter, Comma, Ctrl+Space, Enter, Comma, ... repeatedly until it offers self.

[Veykril]

I agree, I think for pub re-exports it would make sense to just re-export everything visible.

[Tastaturtaste]

I would also like to have this option. I would prefer a separate code assist though.
My use case is the following:
I am writing a ffi library crate and have a module with automatically generated bindings. I import this module privately into another module, which then reexports only the bindings I want, which is most, but not all of them. It would be nice for my workflow if I could expand a glob import of the bindings to then manually delete the ones I don't want to reexport.

[ten3roberts]

I would also like to have this option. I would prefer a separate code assist though. My use case is the following: I am writing a ffi library crate and have a module with automatically generated bindings. I import this module privately into another module, which then reexports only the bindings I want, which is most, but not all of them. It would be nice for my workflow if I could expand a glob import of the bindings to then manually delete the ones I don't want to reexport.

I agree with your workflow. I most often code by adding structs and functions as I go, and then I make a pass to clean up, merge together similar, and choose which are public or not. At that point it would be handy to be able to export all and then remove some.