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()](1ba9a924d7/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>
11367: minor: Use `compare_exchange_weak` in `limit::Limit::check` r=lnicola a=WaffleLapkin
Not a big deal, but generally loops should use `_weak` version of `compare_exchange`.
Co-authored-by: Maybe Waffle <waffle.lapkin@gmail.com>
This patch makes RA understand `#![recursion_limit = "N"]` annotations.
- `crate_limits` query is moved to `DefDatabase`
- `DefMap` now has `recursion_limit: Option<u32>` field
This allows fetching crate limits like `recursion_limit`. The
implementation is currently dummy and just returns the defaults.
Future work: Use this query instead of the hardcoded constant.
Future work: Actually implement this query by parsing
`#![recursion_limit = N]` attribute.
11288: Support <code> blocks from Rust docs in vscode hover r=oandrew a=oandrew
Set `"supportHtml": true` to support rendering `<code>` blocks in hovers.
e.g. 1bd4fdc943/library/std/src/fs.rs (L109)
Co-authored-by: Andrew Onyshchuk <andryk.rv@gmail.com>
11354: fix: More correct `$crate` handling in eager macros r=jonas-schievink a=jonas-schievink
Fixes a few of the additional bugs in https://github.com/rust-analyzer/rust-analyzer/issues/10300, but not yet that issue itself.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11348: fix: Fix merge commit check for git 2.35 r=jonas-schievink a=jonas-schievink
git 2.35 introduces a [change in behavior](89bece5c8c/Documentation/RelNotes/2.35.0.txt (L330-L333)) that breaks this check.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
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>
11345: minor: fix a typo in the style guide r=Veykril a=WaffleLapkin
An example of preferring `<`/`<=` over `>`/`>=` was using `>`.
Co-authored-by: Waffle Maybe <waffle.lapkin@gmail.com>
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>
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+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
