| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
fix: Comment out cast checks for unknown ptr kind
Just like we don't check for types containing unknown.
Fixes #18214.
See also https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Another.20case.20of.20.2318064.3F.
|
|
feat: Highlight exit points of async blocks
Async blocks act similar to async functions in that the await keywords are related, but also act like functions where the exit points are related.
Fixes #18147
|
|
Correctly parse `use` in generic parameters
Fixes: #18225
|
|
|
|
|
|
Run subprocesses async in vscode extension
Extensions should not block the vscode extension host. Replace uses of `spawnSync` with `spawnAsync`, a convenience wrapper around `spawn`.
These `spawnSync`s are unlikely to cause a real issue in practice, because they spawn very short-lived processes, so we aren't blocking for very long. That said, blocking the extension host is poor practice, and if they _do_ block for too long for whatever reason, vscode becomes useless.
|
|
|
