-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-exporting std traits confuses Rust Analyzer #351
Comments
Oh, importantly this is the 1.0.0-beta.6 — I think this is a change introduced by 1.0.0? |
That does seem like quite a bad side-effect of the change. @tyranron what do you think about this. Can you think of a reason to address this? I remember some colleagues complaining about this same issue. |
This sounds related to this rust-analyzer issue. rust-lang/rust-analyzer#11698 We do mark these reexported traits as |
@JelteF yup, I agree that this should be rather fixed on the |
Resolves #351 ## Synopsis Rust-analyzer doesn't ignore `#[doc(hidden)]` exports when they use a glob pattern, only when they explicitely re-export. ## Solution This adds more level of indirection and one more glob pattern so that we put `#[doc(hidden)]` on explicit re-exports. This definitely starts to feel like we're doing hack upon hack here. But ah well, this seems to work. And working well with the most popular LSP for Rust seems worth a bit of a hack.
I'm not sure if this is just a configuration issue on my end, but
rust-analyzer
seems convinced that the only version of traits likeDisplay
orInto
come from this library.This has been particularly annoying when I've gone to import one of these traits automatically, but it only suggests importing the
derive_more
version. I'd rather not have imports fromderive_more
in the modules I'm not using it, so I've been having to manually import things every time this clash happens.A couple of examples — first from a diagnostic:
It should be noted that the file that error is coming from doesn't mention or import
derive_more
anywhere. It's just a carry-over from other modules in the crate using it.And the annoying no-correct-import case:
I'm not sure if there is a clever way around this, but if not, I'd honestly prefer to have to separately import the trait from std!
What do others think / what was the rationale for re-exporting those std traits to begin with?
The text was updated successfully, but these errors were encountered: