11883: fix(ide): move moudle directory when rename r=rainy-me a=rainy-me
fix: #10992
Added `FileSystemEdit::MoveDir` variant for move dirs. Original implemented as recursively move child mod files but had many issues like
1. left empty dir after rename file
2. only affect rust file
3. not performant
so changed to current version
Co-authored-by: rainy-me <github@yue.coffee>
While we don't support const args in type inference yet, we can at least
make use of the fallback path resolution to resolve paths in const args
in the IDE layer to enable some features for them.
11805: fix: Don't try to resolve methods on unknown types r=Veykril a=flodiebold
Fixes#10454, and some type mismatches.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
11791: fix: some fixes and improvements to signature help r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11774: feat: Tag macro calls as unsafe if they expand to unsafe expressions r=Veykril a=Veykril
as long as they aren't inside an unsafe block inside the macro that is.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11663: Internal: Add hir_def::MacroId, add Macro{Id} to ModuleDef{Id} r=Veykril a=Veykril
With this we can now handle macros like we handle ModuleDefs making them work more like other definitions and allowing us to remove a bunch of special cases. This also enables us to track the modules these macros are defined in, instead of only recording the crate they come from.
Introduces a new class of `MacroId`s (for each of the 3 macro kinds) into `hir_def`. We can't reuse `MacroDefId` as that is defined in `hir_expand` which doesn't know of modules, so now we have two different macro ids, this unfortunately requires some back and forth mapping between the two via database accesses which I hope won't be too expensive.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11445: Upstream inlay hints r=lnicola a=lnicola
Closes https://github.com/rust-analyzer/rust-analyzer/issues/2797
Closes https://github.com/rust-analyzer/rust-analyzer/issues/3394 (since now resolve the hints for the range given only, not for the whole document. We don't actually resolve anything due to [hard requirement](https://github.com/rust-analyzer/rust-analyzer/pull/11445#issuecomment-1035227434) on label being immutable. Any further heavy actions could go to the `resolve` method that's now available via the official Code API for hints)
Based on `@SomeoneToIgnore's` branch, with a couple of updates:
- I squashed, more or less successfully, the commits on that branch
- downloading the `.d.ts` no longer works, but you can get it manually from https://raw.githubusercontent.com/microsoft/vscode/release/1.64/src/vscode-dts/vscode.proposed.inlayHints.d.ts
- you might need to pass `--enable-proposed-api matklad.rust-analyzer`
- if I'm reading the definition right, `InlayHintKind` needs to be serialized as a number, not string
- this doesn't work anyway -- the client-side gets the hints, but they don't display
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
11595: fix: lower string literals with actual value instead of default r=lnicola a=tysg
Fixes#11582. Some questions below in the code review section.
Co-authored-by: Tianyi Song <42670338+tysg@users.noreply.github.com>
11490: Correctly fix formatting doc tests with generics r=Veykril a=KarlWithK
Before the doc_test would be outputted like this:
```zsh
"Foo<T, U>::t"
```
However, this would cause problems with shell redirection. I've changed it
so when generics are involved we simply wrap the expression under quotes as so:
```zsh
"\"Foo<T, U>::t\""
```
Note:
At the cost of adding this, I had to allocate a new string via
`format!{}`. However, I argue this is alright as this for just for
outputting the name of the doc test.
The following tests have been changed:
```
runnables::tests::doc_test_type_params
runnables::tests::test_doc_runnables_impl_mod
runnables::tests::test_runnables_doc_test_in_impl
```
Closes https://github.com/rust-analyzer/rust-analyzer/issues/11489
Co-authored-by: KarlWithK <jocelinc60@outlook.com>
Co-authored-by: SeniorMars <jocelinc60@outlook.com>
11481: Display parameter names when hovering over a function pointer r=Veykril a=Vannevelj
Implements #11474
The idea is pretty straightforward: previously we constructed the hover based on just the parameter types, now we pass in the parameter names as well. I went for a quick-hit approach here but I expect someone will be able to point me to a better way of resolving the identifier.
I haven't figured out yet how to actually run my rust-analyzer locally so I can see it in action but the unit test indicates it should work.
Co-authored-by: Jeroen Vannevel <jer_vannevel@outlook.com>
Before the doc_test would be outputted like this:
"Foo<T, U>::t"
However, this would cause shells with shell redirection. I've changed it
so when generics are involved we simply wrap the expression under escape
chanters as so:
"\"Foo<T, U>::t\""
Note:
At the cost of adding this, I had to allocate a new string via
format!{}. However, I argue this is alright as this for just for
outputting the name of the doc test.
The following tests have been changed:
runnables::tests::doc_test_type_params
runnables::tests::test_doc_runnables_impl_mod
runnables::tests::test_runnables_doc_test_in_impl
11369: feat: Add type hint for keyword expression hovers r=Veykril a=danii
Adds the return type of keywords to tool-tips where it makes sense. This applies to: `if`, `else`, `match`, `loop`, `unsafe` and `await`. Thanks to `@Veykril` for sharing the idea of putting return type highlighting on other keywords!
Closes#11359
Co-authored-by: Daniel Conley <himself@danii.dev>
11281: ide: parallel prime caches r=jonas-schievink a=jhgg
cache priming goes brrrr... the successor to #10149
---
this PR implements a parallel cache priming strategy that uses a topological work queue to feed a pool of worker threads the crates to index in parallel.
## todo
- [x] should we keep the old prime caches?
- [x] we should use num_cpus to detect how many cpus to use to prime caches. should we also expose a config for # of worker CPU threads to use?
- [x] something is wonky with cancellation, need to figure it out before this can merge.
Co-authored-by: Jake Heinz <jh@discordapp.com>
