| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
internal: Add StaticLifetime to hir API
|
|
|
|
|
|
fix: Don't emit --keep-going for custom build script commands
Might be the cause for https://github.com/rust-lang/rust-analyzer/issues/17231
|
|
|
|
fix: extract mod to file should respect path attribute
close https://github.com/rust-lang/rust-analyzer/issues/17181
|
|
fix: Hash file contents to verify whether file actually changed
Fixes https://github.com/rust-lang/rust-analyzer/issues/16580
|
|
|
|
|
|
Expand macro recursively expands both fp-like and attribute macros when intertwined
|
|
|
|
Bump Cargo.lock
|
|
|
|
|
|
internal: Lazier macro parse tree validation
|
|
|
|
|
|
fix: Improve confusing literal hovers
|
|
|
|
|
|
Fix OOM caused by term search
The issue came from multi Cartesian product for exprs with many (25+) arguments, each having multiple options.
The solution is two fold:
### Avoid blowing up in Cartesian product
**Before the logic was:**
1. Find expressions for each argument/param - there may be many
2. Take the Cartesian product (which blows up in some cases)
4. If there are more than 2 options throw them away by squashing them to `Many`
**Now the logic is:**
1. Find expressions for each argument/param and squash them to `Many` if there are more than 2 as otherwise we are guaranteed to also have more than 2 after taking the product which means squashing them anyway.
2. Take the Cartesian product on iterator
3. Start consuming it one by one
4. If there are more than 2 options throw them away by squashing them to `Many` (same as before)
This is also why I had to update some tests as the expressions get squashed to many more eagerly.
### Use fuel to avoid long search times and high memory usage
Now all the tactics use `should_continue: Fn() -> bool` to chech if they should keep iterating _(Similarly to chalk)_.
This reduces the search times by a magnitude, for example from ~139ms/hole to ~14ms/hole for `ripgrep` crate.
There are slightly less expressions found, but I think speed gain worth it for usability.
Also note that syntactic hits decreases more because of squashing so you simple need to run search multiple times to get full terms.
Also the worst case time (For example `nalgebra` crate cus it has tons of generics) has search times mostly under 200ms.
Benchmarks on `ripgrep` crate
Before:
```
Tail Expr syntactic hits: 291/1692 (17%)
Tail Exprs found: 1253/1692 (74%)
Term search avg time: 139ms
````
After:
```
Tail Expr syntactic hits: 239/1692 (14%)
Tail Exprs found: 1226/1692 (72%)
Term search avg time: 14ms
```
|
|
|
|
use the repository field to link to the repository
|
|
fix: keep parentheses when the precedence of inner expr is lower than the outer one
fix #17185
Additionally, this PR simplifies some code in `apply_demorgan`.
|
|
Implement unsafe attribute parsing
|
|
|
|
|
|
If rust-analyzer receives a malformed LSP request, the IO thread
terminates with a meaningful error, but then closes the channel.
Once the channel has closed, the main_loop also terminates, but it
only has RecvError and can't show a meaningful error. As a result,
rust-analyzer would incorrectly claim that the client forgot to
shutdown.
```
$ buggy_lsp_client | rust-analyzer
Error: client exited without proper shutdown sequence
```
Instead, include both error messages when the server shuts down.
|
|
|
|
|
|
Fix source_range for INT_NUMBER in completion
fix #17179.
Previously r-a use `TextRange::empty(self.position.offset)` as `source_range` for `INT_NUMBER`, so the `text_edit` would always be an insertion, which results in #17179.
This PR changed it by using `text_range` of `original_token` (same as `IDENT`).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
outer one
|
|
The documentation for `lens.run.enable` states that it only applies
when `lens.enable` is set. However, the config setting whether to show
the Run lens did not check `lens.enable`, so the Run lens would show
even though lenses were disabled.
|
|
In the stabilization attempt of `#[unix_sigpipe = "sig_dfl"]`, a concern
was raised related to using a language attribute for the feature: Long
term, we want `fn lang_start()` to be definable by any crate, not just
libstd. Having a special language attribute in that case becomes
awkward.
So as a first step towards towards the next stabilization attempt, this
PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag
`-Zon-broken-pipe=...` to remove that concern, since now the language
is not "contaminated" by this feature.
Another point was also raised, namely that the ui should not leak
**how** it does things, but rather what the **end effect** is. The new
flag uses the proposed naming. This is of course something that can be
iterated on further before stabilization.
|
|
Fix impl trait params not being counted properly
Fixes the other thing in https://github.com/rust-lang/rust-analyzer/issues/17173, this just rolls back a change from https://github.com/rust-lang/rust-analyzer/pull/17175 and adds a comment as to what it does
|
|
|
|
fix: Fix implicit ty args being lowered where they shouldn't
Fixes https://github.com/rust-lang/rust-analyzer/issues/17173
|
