internal: Re-use the resolver in `InferenceContext` instead of rebuilding it whenever needed
This reduced inference time on my local build by roughly ~1 sec (out of like 60)
internal: Handle fields called as method calls as the fields they resolve to
Confusing PR title tbf but this makes it so `bar` in `foo.bar()` resolves to the field if it exists and no method with the same name exists. Improves UX slightly when incorrectly calling a field.
generate correct completion edits for missing macro arguments
Fixes#14246
rust-analyzer used the token at the cursor after macro expansion to decide whether to replace the token at the cursor before macro expansion. In most cases these two are the same but in some cases these can mismatch which can lead to incorrect replacements.
For example if an ident/expr macro argument is missing rust-analyzer generates a "missing" identifier as a placeholder, there is only a brace at the cursor. Therefore, rust-analyzer will incorrectly replace the macro brace with the completion in that case leading to #14246.
Using the expanded token type was intentional. However, this doesn't seem to ever be desirable (this is supported by the fact that there were no tests that relied on this behavior) since the type of edit to perform should always be determined by the token it's actually applied to. Therefore this PR simply switches the relevant match to use the unexpanded token instead
rust-analyzer used the token at the cursor after macro expansion
to decide whether to replace the token at the cursor before macro
expansion. In most cases these two are the same but in some cases these
can mismatch which can lead to incorrect replacements.
For example if an ident/expr macro argument is missing rust-analyzer
generates a "missing" identifier as a placeholder, there is only a
brace at the cursor. Therefore, rust-analyzer will incorrectly replace
the macro brace with the completion in that case leading to #14246.
Using the expanded token type was intentional. However, this doesn't
seem to ever be desirable (this is supported by the fact that there
were no tests that relied on this behavior) since the type of edit to
perform should always be determined by the token it's actually applied
to.
Handle trait alias definitions
Part of #2773
This PR adds a bunch of structs and enum variants for trait aliases. Trait aliases should be handled as an independent item because they are semantically distinct from traits.
I basically started by adding `TraitAlias{Id, Loc}` to `hir_def::item_tree` and iterated adding necessary stuffs until compiler stopped complaining what's missing. Let me know if there's still anything I need to add.
I'm opening up this PR for early review and stuff. I'm planning to add tests for IDE functionalities in this PR, but not type-related support, for which I put FIXME notes.
feat: allow `generate_function` to generate in different local crate
Closes#14224
This PR allows `generate_function` assist to generate in crates other than the current one. I took a step further from the original request and made it allow to generate in any local crates since it looked reasonable and IDE layer doesn't really know about packages.
(actually we have been checking which crate we're generating in only for methods and not for freestanding functions, so we were providing the assist for `std::foo$0()`; it's both feature and fix in a sense)
The first commit is a drive-by fix unrelated to the feature.
