| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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.
|
|
|
|
|
|
feat: respect references.exclude_tests in call-hierarchy
close #18212
### Changes
1. feat: respect `references.exclude_tests` in call-hierarchy
2. Modified the description of `references.exclude_tests`
|
|
Skip #[test_case] expansion
Fixes #18274, although I don't fully understand if this is the best fix (it's not clear to me why this didn't cause issues before https://github.com/rust-lang/rust-analyzer/pull/18085).
|
|
Add support for LLDB-DAP
|
|
fix: Do not consider mutable usage of deref to `*mut T` as deref_mut
Fixes #15799
We are doing some heuristics for deciding whether the given deref is deref or deref_mut here;
https://github.com/rust-lang/rust-analyzer/blob/5982d9c420d0dc90739171829f0d2e9c80d98979/crates/hir-ty/src/infer/mutability.rs#L182-L200
But this heuristic is erroneous if we are dereferencing to a mut ptr and normally those cases are filtered out here as builtin;
https://github.com/rust-lang/rust-analyzer/blob/5982d9c420d0dc90739171829f0d2e9c80d98979/crates/hir-ty/src/mir/lower/as_place.rs#L165-L177
Howerver, this works not so well if the given dereferencing is double dereferencings like the case in the #15799.
```rust
struct WrapPtr(*mut u32);
impl core::ops::Deref for WrapPtr {
type Target = *mut u32;
fn deref(&self) -> &Self::Target {
&self.0
}
}
fn main() {
let mut x = 0u32;
let wrap = WrapPtr(&mut x);
unsafe {
**wrap = 6;
}
}
```
Here are two - outer and inner - dereferences here, and the outer dereference is marked as deref_mut because there is an assignment operation.
And this deref_mut marking is propagated into the inner dereferencing.
In the later MIR lowering, the outer dereference is filtered out as it's expr type is `*mut u32`, but the expr type in the inner dereference is an ADT, so this false-mutablility is not filtered out.
This PR cuts propagation of this false mutablilty chain if the expr type is mut ptr.
Since this happens before the resolve_all, it may have some limitations when the expr type is determined as mut ptr at the very end of inferencing, but I couldn't find simple fix for it 🤔
|
|
internal: Don't resolve extern crates in import fix point resolution
The fix point loop won't progress them given the potential extern crate candidates are set up at build time.
|
|
fix: Join rustfmt overrideCommand with project root
When providing a custom rustfmt command, join it with the project root instead of the workspace root. This fixes rust-analyzer getting the wrong invocation path in projects containing subprojects.
This makes the behaviour consistent with how a custom path provided in rust-analyzer.procMacro.server behaves already.
Resolves issue #18222
|
