Auto merge of #11956 - fee1-dead:master, r=flodiebold
feat: allow customizing the command for running build scripts
I have tested this locally and it fixed #9201 with some small changes on the compiler side with suggestions from https://github.com/rust-analyzer/rust-analyzer/issues/9201#issuecomment-1019554086.
I have also added an environment variable `IS_RA_BUILDSCRIPT_CHECK` for crates to detect that it is a check for buildscripts, and allows defaulting to bogus values for expected environment variables.
11969: fix: Add trailing `;` when completing assoc const/type in trait impl r=jonas-schievink a=jonas-schievink
Final item of https://github.com/rust-analyzer/rust-analyzer/issues/11860, thus closes https://github.com/rust-analyzer/rust-analyzer/issues/11860 :tada:
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11964: internal: Show more project building errors to the user r=Veykril a=Veykril
Something very fishy is going on with the `rustc_workspace` handling, which caused this bug to only manifest in the `std` library but not other library crate... So there is either a bug there or just the fact that we seem to add duplicate dependencies (I think this is what we are doing with this right?) might be tripping something up somewhere.
cc https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Rust-analyzer.20use.20inside.20stdlib
11958: Show config deseralization failures on start up r=Veykril a=Veykril
We now also show deserialization errors to the user when starting the server.
This PR also adds a small validation "pass" on the config that we will probably populate over time with more checks.
Signed-off-by: Alex Chi <iskyzh@gmail.com>
This is still a workaround on GAT panic, and didn't solve the full problem. But at least we won't panic now. False positive is better than panicking and letting VSCode constantly pop out the warning 🤣
This PR is simple -- only apply the https://github.com/rust-analyzer/rust-analyzer/pull/11878 fix on const generics. For normal GATs, just follow the previous approach.
This PR fixes https://github.com/rust-analyzer/rust-analyzer/issues/11939, I've added it as a test case.
This PR didn't fully fix / https://github.com/rust-analyzer/rust-analyzer/issues/11923. But at least it won't panic now -- will only give a type mismatch error.
Not sure if it fixes / https://github.com/rust-analyzer/rust-analyzer/issues/11921, I'll test it later.
Account for macro-generated items, increase the score of these completions since they're very relevant, and allow them to trigger when the cursor is directly in the assoc. item list without requiring further input.
11936: Ignore `Drop` and `Destruct` bounds for now r=flodiebold a=flodiebold
- `T: ~const Drop` has a special meaning in Rust 1.61 that we don't implement. (So ideally, we'd only ignore `~const Drop`, but this should be fine for now.)
- `Destruct` impls are built-in in 1.62 (current nightlies), so until the builtin impls are supported by Chalk, we ignore them as well. Since `Destruct` is implemented for everything in non-const contexts IIUC, this should also work fine.
- `T: ~const Drop` has a special meaning in Rust 1.61 that we don't implement.
(So ideally, we'd only ignore `~const Drop`, but this should be fine
for now.)
- `Destruct` impls are built-in in 1.62 (current nightlies as of 08-04-2022), so until
the builtin impls are supported by Chalk, we ignore them as well.
Since `Destruct` is implemented for everything in non-const contexts
IIUC, this should also work fine.
11920: Consider types of const generics r=flodiebold a=HKalbasi
fix #11913
We should emit type_mismatch in const generics, probably after #7434. Currently they will lead to a misleading, time of use type error (like the added test).
This flag was determined purely based on the AST, which cannot work reliably since macros are allowed in `extern` blocks (in which case the function would not have an extern block parent in the AST).
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11915: fix: Attempt to resolve paths in const arguments heuristically in IDE layer r=Veykril a=Veykril
While we don't support const args in type inference yet, we can at least
make use of the fallback path resolution to resolve paths in const args
in the IDE layer to enable some features for them.
fix: Attempt to resolve paths in const arguments heuristically
While we don't support const args in type inference yet, we can at least
make use of the fallback path resolution to resolve paths in const args
in the IDE layer to enable some features for them.
This check is insufficient to ensure finite macro nesting, and so all callers already have their own recursion limit, which makes this check redundant.
...at least I hope it's redundant. Would be great if someone could double-check this.
Originally, this check was added in https://github.com/rust-analyzer/rust-analyzer/pull/3671
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11891: Better error message on Flycheck Error message (from: unactionable error message if we are using `clippy` as the checker) r=Veykril a=flipbit03
I have commented on this [S-unactionable issue](https://github.com/rust-analyzer/rust-analyzer/issues/6589) that the Flycheck error message should maybe provide a hint about what tool it actually runs. Searching on some places on the Internet I've found multiple people, including myself, losing copious amounts of time on the same issue. So I've decided to make this very small PR :-)
From an user experience standpoint, the current error message is unhelpful to the end user, because the end user does not know exactly what it needs to check/fix (outdated, broken, or missing `cargo clippy`). In my own case, `cargo clippy` was actually missing altogether (developing off `rust:1.59.0-bullseye` official Docker image).
11899: fix: Skip match check on patterns of unexpected TyKind::FnDef r=Veykril a=iDawer
Match checking does not expect patterns of `TyKind::FnDef` type.
It seems that in _rustc_ match checking is ruled out due to such type errors at the typecheck stage.
11894: complete pattern args based on type name r=Veykril a=cameron1024
Addresses #11892
Changes function argument completion to cover a case like this:
```rust
struct Foo { bar: i32 }
fn qux(Foo { bar }: Foo) {
println!("{bar}");
}
```
When completing the function call for `qux`, instead of expanding to `qux(_)`, it will now expand to `qux(foo)` (based on the snake-cased version of the name of the ADT)
projects / rust.git / log