feat: Prioritize import suggestions based on the expected type
Hi, this is a draft PR to solve #15384. `Adt` types work and now I have a few questions :)
1. What other types make sense in this context? Looking at [ModuleDef](05666441ba/crates/hir/src/lib.rs (L275)) I am thinking everything except Modules.
2. Is there an existing way of converting between `ModeuleDef` and `hir::Type` in the rustanalyzer code base?
3. Does this approach seem sound to you?
Ups: Upon writing this I just realised that the enum test is invalided as there are no enum variants and this no variant is passed as a function argument.
fix: resolve Self type references in delegate method assist
This PR makes the delegate method assist resolve any `Self` type references in the parameters or return type. It also works across macros such as the `uint_impl!` macro used for `saturating_mul` in the issue example.
Closes#14485
fix: Fix item tree lowering pub(self) to pub()
Prior to this, the item tree lowered `pub(self)` visibility to `pub()`
Fix#15134 - tested with a unit test and
a manual end-to-end test of building rust-analyzer from my branch and opening the reproduction repository
Before
Private functions have RawVisibility module, but were
missed because take_types returned None early. After resolve_visibility
returned None, Visibility::Public was set instead and private functions
ended up being offered in autocompletion.
Choosing such a function results in an immediate error diagnostic
about using a private function.
After
Pattern match of take_types that returns None and
query for Module-level visibility from the original_module
Fix#15134 - tested with a unit test and a manual end-to-end
test of building rust-analyzer from my branch and opening
the reproduction repository
REVIEW
Refactor to move scope_def_applicable and check function visibility
from a module
Please let me know what's the best way to add a unit tests to
nameres, which is where the root cause was
Fix panic with closure inside array len
I was working on #15947 and found out that we panic on this test:
```
fn main() {
let x = [(); &(&'static: loop { |x| {}; }) as *const _ as usize]
}
```
This PR fixes the panic. Closures in array len are still broken, but closure in const eval is not stable anyway.
fix: bug in extract_function.rs
There is a little bug in extract_function: It appends `use path::to::ControlFlow;` if the function created contains string "ControlFlow".
A case below (also in the test named `does_not_import_control_flow` which will fail in the original code)
<img width="322" alt="image" src="4b80bb58-0cfd-4d56-b64c-d9649eed336e">
<img width="391" alt="image" src="3d7262f4-8a4c-44ea-822d-304b8b23fe28">
Now I have changed the condition determining whether adding import statement. Only when the new function body contains ControlFlow::Break or ControlFlow::Continue can the import statement be added.
Last related PR: https://github.com/rust-lang/rust-analyzer/pull/10309
feat: Allow navigation targets to be duplicated when the focus range lies in the macro definition site
Basically if a name of an item originates from the macro definition we now point to that as well as the creating macro call.
Big diff because I also made `FileId`s field private due to some debugging I had to do (having a searchable constructor makes things easier).
fix: Insert fn call parens only if the parens inserted around field name
Fixes#16014.
Sorry I missed it in previous PR. I've added a test as level to prevent regressions again.
Give any suggestions to improve the test if anything.
