Handle visibility (privacy) in field/method completion

[flodiebold]

We currently don't handle visibility at all. This means that we provide lots of private fields and methods for completions outside of modules where you can actually access them. We should fix this. I think the basic steps for this will be:

• add visibility to the HIR for StructField and Function (probably also Const, Type etc.)
• implement the code to check whether a field/method is visible from a certain module (basically, if the item is private, are we in the module where it's defined or a submodule? notably, for impl items, the privacy is determined by the module containing the impl, not the one containing the type, I think)
• filter out completions that are not visible in complete_dot.rs

A different, but related issue is handling visibility of items, for example when doing glob imports.

[sirgl]

I think, that it would be better not to filter out items, but make it less relevant and sort completion results by relevancy. Very often I forget to add pub and try to complete it somewhere else, so it is not very convenient to go there and add visibility manually. I think, that assist to add pub for not visible entry should be created. It would be much better user experience

[DJMcNab]

But do filter it out for external crates?

[flodiebold]

It probably makes sense to treat the local source roots differently than the other ones (i.e. provide private items only from crates you can edit).

[sanbox-irl]

Hiya -- i'd like to see this added. I think the optimal configuration is:

1. By default, we only show publicly accessible things in the current scope
2. we provide a setting to turn this off (perhaps even allowing us to sort, though I think that's a bit silly personally)

The reason for this is a few -- first, I like the Rust analyzer being able to tell me at a glance what's in scope and not in scope. Secondly, I really dislike the idea of the Rust Analyzer being willing to autocomplete something which will not compile. As a given rule, I think the Rust analyzer shouldn't suggest things which are wrong. Scope errors are one of those things. Finally, I think this could be rolled into a larger process of having the Rust Analyzer handle scope for the user much more effectively (think a help action to automatically add a using directive, like Omnisharp has for C#).

Thank you!

[lnicola]

I think VS puts public items in front and private ones at the end, which doesn't sound so bad if you have a way to distinguish them.

[pksunkara]

#2830 seems a duplicate of this.

[jonas-schievink]

Hmm, this seems to be mostly implemented now. Is anything missing here?

[Veykril]

We still got two visibility related FIXMEs here https://github.com/rust-analyzer/rust-analyzer/blob/444679f202742c8fd00e9d1c7fddfaa9a067e640/crates/ide_completion/src/completions/dot.rs#L59-L78