| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
feat: support initializeStopped setting
See #18356
Add option to start rust-analyzer in "stopped" state when the extension activates.
|
|
Add wrap/unwrap return type in Option
I pretty much just copied over the code and tests for wrapping/unwrapping return types in `Result` and then did a bunch of find and replace changes.
I handled unwrapping statements returning `None` by just replacing `None` with the unit type, but I'm open to suggestions for more intuitive behavior here.
|
|
fix: private items are shown in completions for modules in fn body
Close: #18287
|
|
|
|
|
|
|
|
|
|
This brings in the new optimized algorithm that was shown to have small performance benefits for
rustc.
|
|
|
|
fix: classify `safe` as a contextual kw
fix #18352
|
|
|
|
And few more fixups.
I was worried this will lead to more memory usage since `ExprOrPatId` is double the size of `ExprId`, but this does not regress `analysis-stats .`. If this turns out to be a problem, we can easily use the high bit to encode this information.
|
|
Instead of lowering them to `<expr> = <expr>`, then hacking on-demand to resolve them, we lower them to `<pat> = <expr>`, and use the pattern infrastructure to handle them. It turns out, destructuring assignments are surprisingly similar to pattern bindings, and so only minor modifications are needed.
This fixes few bugs that arose because of the non-uniform handling (for example, MIR lowering not handling slice and record patterns, and closure capture calculation not handling destructuring assignments at all), and furthermore, guarantees we won't have such bugs in the future, since the programmer will always have to explicitly handle `Expr::Assignment`.
Tests don't pass yet; that's because the generated patterns do not exist in the source map. The next commit will fix that.
|
|
Because our lint infra *can* handle allows from within macro expansions!
(Also, what did this reason have to do with something that is a hard error and not a lint? I'm puzzled).
I wonder how many such diagnostics we have...
Maybe that also mean we can change `unused_mut` to no-longer-experimental? But this is a change I'm afraid to do without checking.
|
|
|
|
|
|
|
|
compiler: Adopt rust-analyzer impls for `LayoutCalculatorError`
We're about to massively churn the internals of `rustc_abi`. To minimize the immediate and future impact on rust-analyzer, as a subtree that depends on this crate, grow some API on `LayoutCalculatorError` that reflects their uses of it. This way we can nest the type in theirs, and they can just call functions on it without having to inspect and flatten-out its innards.
|
|
|
|
|
|
Fix: Increase TOKEN_LIMIT in hir-expand
Due to the `TOKEN_LIMIT`, rust-analyzer failed to expand macro for `web-sys::WebGl2RenderingContext` https://github.com/rustwasm/wasm-bindgen/blob/main/crates/web-sys/src/features/gen_WebGl2RenderingContext.rs
<img width="780" alt="image" src="https://github.com/user-attachments/assets/3a39f18e-656e-43df-9994-0a0179fa42ac">
<img width="403" alt="image" src="https://github.com/user-attachments/assets/7ae8dcf9-a40a-4070-8623-dd3a953bbf45">
After increasing the `TOKEN_LIMIT`, the `web-sys::WebGl2RenderingContext` can be expanded successfully:
<img width="459" alt="image" src="https://github.com/user-attachments/assets/76a71763-05a5-4f14-a5c9-61fc190c668f">
|
|
internal: Fix editorconfig glob
Had been testing Zed's editorconfig branch on r-a and noticed that something was odd with yaml files.
https://spec.editorconfig.org/#glob-expressions
> {s1,s2,s3}
> any of the strings given (separated by commas, can be nested) (But {s1} only matches {s1} literally.)
|
|
|
|
|
|
|
|
|
|
LSP says about Position::character
> If the character value is greater than the line length it defaults back to the line length.
but from_proto::offset() doesn't implement this.
A client might for example request code actions for a whole line by sending
Position::character=99999. I don't think there is ever a reason (besides laziness) why the
client can't specify the line length instead but I guess we should not crash but follow protocol.
Technically it should be a warning, not an error but warning is not shown by default so keep
it at error I guess.
Fixes #18240
|
|
|
|
r=Veykril
internal: fix lldb-dap unconditionally calling rustc
Fixes https://github.com/rust-lang/rust-analyzer/issues/18318. I also took the opportunity to refactor how `discoverSourceFileMap` worked—it now returns a type instead of mutating a map in place.
I tested this change using the LLDB DAP extension. I needed to set `"lldb-dap.executable-path": "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb-dap"` for everything to work, however, but once I did, was able to successfully debug a test.
|
|
Clamp Position::character to line length
LSP says about Position::character
> If the character value is greater than the line length it defaults back to the line length.
but from_proto::offset() doesn't implement this.
A client might for example request code actions for a whole line by sending
Position::character=99999. I don't think there is ever a reason (besides laziness) why the
client can't specify the line length instead but I guess we should not crash but follow protocol.
Not sure how to update Cargo.lock (lib/README.md doesn't say how).
Fixes #18240
|
|
internal: Add more trivially `Sized` types to `is_sized` check
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When debugging rust-analyzer and looking at logs, it's much easier to read
when the timestamp is in the local timezone.
Before:
2024-08-28T20:55:38.792321Z INFO ParseQuery: invoked at R18460
After:
2024-08-28T13:55:38.792321-07:00 INFO ParseQuery: invoked at R18460
|
|
Part of #18240
|
|
Do not consider match/let/ref of place that evaluates to ! to diverge, disallow coercions from them too
Resolves #18237
|
|
|
|
|
|
disallow coercions from them too
|
|
feat: handle self-param outside of methods when renaming
close #17427
|
|
|
|
chore: rename `salsa` to `ra_salsa`
Laying some groundwork to start before I import the new Salsa crate. Here's why:
1. As part of the migration, `@darichey,` `@Wilfred,` and I will create new Salsa equivalents of the existing databases/query groups. We'll get them to compile crate-by-crate.
2. Once we wrote all equivalents of all queries, we'd start to refactor usage sites of the vendored Salsa to use the new Salsa databases.
3. Starting porting usage sites of old Salsa to the new Salsa.
4. Remove the vendored `ra_salsa`; declare victory.
|
