bors[bot] [Tue, 1 Feb 2022 23:05:28 +0000 (23:05 +0000)]
Merge #11322
11322: Extract function also extracts comments r=Vannevelj a=Vannevelj
Fixes #9011
The difficulty I came across is that the original assist works from the concept of a `ast::StmtList`, a node, but that does not allow me to (easily) represent comments, which are tokens. To combat this, I do a whole bunch of roundtrips: from the `ast::StmtList` I retrieve the `NodeOrToken`s it encompasses.
I then cast all `Node` ones back to a `Stmt` so I can apply indentation to it, after which it is again parsed as a `NodeOrToken`.
Lastly, I add a new `make::` api that accepts `NodeOrToken` rather than `StmtList` so we can write the comment tokens.
bors[bot] [Mon, 31 Jan 2022 16:03:23 +0000 (16:03 +0000)]
Merge #11388
11388: fix: Fix proc-macro server not using the supplied span in Ident::new r=Veykril a=Veykril
This makes the hack introduced by https://github.com/rust-analyzer/rust-analyzer/pull/10899 obsolete.
For async-trait specifically, (unfortunately, but technically correct) due to how async-trait works, the self local now renders white, as it now resolves to the `__self` local introduced by the attribute.
bors[bot] [Mon, 31 Jan 2022 11:16:22 +0000 (11:16 +0000)]
Merge #11182
11182: fix: don't panic on seeing an unexpected offset r=Veykril a=dimbleby
Intended as a fix, or at least a sticking plaster, for #11081.
I have arranged that [offset()](https://github.com/rust-analyzer/rust-analyzer/blob/1ba9a924d7b161c52e605e157ee16d582e4a8684/crates/ide_db/src/line_index.rs#L105-L107) returns `Option<TextSize>` instead of going out of bounds; other changes are the result of following the compiler after doing this.
Perhaps there's still an issue here - I suppose the server and client have gotten out of sync and that probably shouldn't happen in the first place? I see that https://github.com/rust-analyzer/rust-analyzer/issues/10138#issuecomment-913727554 suggests what sounds like a more substantial fix which I think might be aimed in this direction. So perhaps that one should be left open to cover such things?
Meanwhile, I hope that not-crashing is a good improvement: and I can confirm that it works out just fine in the repro I have at #11081.
Co-authored-by: David Hotham <david.hotham@metaswitch.com>
bors[bot] [Fri, 28 Jan 2022 13:21:24 +0000 (13:21 +0000)]
Merge #11365
11365: Add a way to disable dll copying for users of proc_macro_srv library r=lnicola a=vlad20012
We use `ra_ap_proc_macro_srv` library in IntelliJ Rust in order to expand proc macros. We need a way to disable [DLL copying to a temp dir on Windows](https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/proc_macro_srv/src/dylib.rs#L166) behavior because it causes issues like https://github.com/intellij-rust/intellij-rust/issues/7709. Unlike RA, file locking is not an issue for IntelliJ Rust because we copy DLLs to a temp dir before calling the expander.
git 2.35 introduces a [change in behavior](https://github.com/git/git/blob/89bece5c8c96f0b962cfc89e63f82d603fd60bed/Documentation/RelNotes/2.35.0.txt#L330-L333) that breaks this check.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
bors[bot] [Wed, 26 Jan 2022 17:35:51 +0000 (17:35 +0000)]
Merge #11347
11347: fix: Fix resolution of eager macro contents r=jonas-schievink a=jonas-schievink
Eager macros resolve and expand any contained macro invocations before they are expanded. The logic for this was previously pretty broken: any nameres failure would be reported as a generic macro expansion error, so this didn't work correctly with the fixed-point resolution loop. This manifested as spurious errors whenever a non-legacy macro was used in an eager macro (that means *any* path with more than one segment).
After an intense staring contest with the abyss, this PR fixes the basic logic, but some bugs still remain (particularly around `$crate`). As a side-effect, this PR moves `ModPath` into `hir_expand`.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
bors[bot] [Tue, 25 Jan 2022 16:03:35 +0000 (16:03 +0000)]
Merge #11281
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.
bors[bot] [Sun, 23 Jan 2022 16:43:22 +0000 (16:43 +0000)]
Merge #11334
11334: fix: don't panic in semantics due to `cfg_attr` disrupting offsets r=Veykril a=Veykril
Reduces the panic in https://github.com/rust-analyzer/rust-analyzer/issues/11298 to an early return, that means we won't resolve these cases again for now, but this is better than constantly panicking in highlighting and hovering.
bors r+
I'm a bit unsure about this change since this might have unanticipated consequences, but this does fix https://github.com/rust-analyzer/rust-analyzer/issues/11300.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
bors[bot] [Mon, 17 Jan 2022 23:57:30 +0000 (23:57 +0000)]
Merge #11311
11311: fix: insert auto-imports after header comments r=repnop a=repnop
Fixes #8607.
This commit changes the auto-import functionality and causes it to add imports after any leading comments, which are commonly license headers. This does not affect comments on items as they're considered part of the item itself and not separate.
Wesley Norris [Mon, 17 Jan 2022 22:06:10 +0000 (17:06 -0500)]
fix: insert auto-imports after header comments
Fixes #8607.
This commit changes the auto-import functionality and causes it to add
imports after any leading comments, which are commonly license headers.
This does not affect comments on items as they're considered part of the
item itself and not separate.
bors[bot] [Mon, 17 Jan 2022 17:12:14 +0000 (17:12 +0000)]
Merge #11308
11308: fix: status: output all crates a file belongs to r=jonas-schievink a=jonas-schievink
While investigating https://github.com/rust-analyzer/rust-analyzer/issues/11300 I noticed that we only output the first crate, which masks the reason for that issue – the file in question is the root of multiple crates, and one is missing dependencies.
This PR makes "Rust Analyzer: Status" include *every* crate a file is part of.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>