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
Check if lhs is also a binexpr and use its rhs in flip binexpr assist
Closes#15508
From the original PR, flip binexpr assist is not meant to preserve equivalence, so I went with the simplest solution here.
I can add some extra checks to keep equivalence, but I think they should go in different specific assists (eg. flip arith op / flip logic op / etc), otherwise this one will get out of hand pretty quickly.
Show placeholder while run command gets runnables from server
This PR fixes a UI annoyance in the VS Code extension when working in large codebases where rust-analyzer can take a few moments to interact with the server. Scenario:
1. Invoke "rust-analyzer: Run" from the command palette or hotkey
2. Quickly start typing to filter the list (or press Enter to accept the last runnable)
We often do this quickly from muscle memory without waiting to see the picker. The picker often takes several seconds to come up, causing us to type garbage into the currently open editor.
Fix:
Show a placeholder item before we call out to the server.
Selecting this item does nothing so if the user accidentally hits Enter nothing happens.
The list is populated and the placeholder dismissed when the actual runnables are retrieved. From here the behavior is the same as before.
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 WideChar offsets calculation in `line-index`
Fix#15981. This PR addresses the issue with the WideChar's offset calculation, ensuring accurate line-specific positions during text analysis in the `lib/line-index` module.
## Changes Made
- Corrected the calculation for `WideChar` offsets, ensuring they reflect positions within respective lines.
- Added tests to verify the accuracy of `WideChar` offset calculations, and correct existing tests.
make ParamLoweringMode accessible
In `hir-ty`, the `TyLoweringContext` has functions `pub fn with_impl_trait_mode` and `pub fn with_type_param_mode`, which can be used to fine-tune certain lowering properties.
Each of these takes one enum (either `pub enum ImplTraitLoweringMode`, or `pub enum ParamLoweringMode`), which encodes the possible configuration options.
To then make this usable for other crates, `TyLoweringContext` and `ImplTraitLoweringMode` are exported. Unfortuntely, `ParamLoweringMode` is not. This means that while the method can be called, there are no useful values to call it with.
Presumably this is an oversight. It would be great if this was made actually public.
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).
Add support for making lib features internal
We have the notion of an "internal" lang feature: a feature that is never intended to be stabilized, and using which can cause ICEs and other issues without that being considered a bug.
This extends that idea to lib features as well. It is an alternative to https://github.com/rust-lang/rust/pull/115623: instead of using an attribute to declare lib features internal, we simply do this based on the name. Everything ending in `_internals` or `_internal` is considered internal.
Then we rename `core_intrinsics` to `core_intrinsics_internal`, which fixes https://github.com/rust-lang/rust/issues/115597.
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.
