8692: Fix panic caused by new Try trait definition r=flodiebold a=flodiebold
The new Try trait definition caused a query cycle for us. This adds recovery for that cycle, but also fixes the cause, which is that we went through the supertraits when resolving `<T as Trait>::Assoc`, which isn't actually necessary. I also rewrote `all_super_trait_refs` to an iterator before I realized what the actual problem was, so I kept that.
Fixes#8686.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
8687: fix: closure unify without check ClosureId r=lnicola a=komonad
Previously, the unification of closure types is blocked by `Ty.equals_ctor` which compares the ClosureId of the closures. Here is a workaround to allow closures to unify their substitutions.
Fixes#8604.
Co-authored-by: Comonad <comonad@foxmail.com>
8685: feat: parse const param defaults r=jonas-schievink a=jonas-schievink
These will probably be stabilized in a few releases, let's make sure we can at least parse them
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8683: internal: ensure that client and server-side configs are not mixed up r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
8624: Automatically detect rust library source file map r=vsrs a=vsrs
This PR adds a new possible `rust-analyzer.debug.sourceFileMap` value:
```json
{
"rust-analyzer.debug.sourceFileMap": "auto"
}
```
I did not make it the default because it uses two shell calls (`rustc --print sysroot` and `rustc -V -v`). First one can be slow (https://github.com/rust-lang/rustup/issues/783)
Fixes#8619
Co-authored-by: vsrs <vit@conrlab.com>
8629: Allow pressing | to surround closure arguments in VSCode r=matklad a=Smittyvb
This makes pressing <kbd>|</kbd> while some text is selected surround that text with pipes. This is useful when writing closures.
In this demo, I press <kbd>|</kbd> to easily surround some text (`predicate`) with pipe characters to create a closure. Before, this would have replaced `predicate` with just `|`.
(I am getting failures when I do `cargo test` even on `master` locally (due to #8585 I think), but GH Actions is fine with this)
8657: npm update r=matklad a=kjeremy
Co-authored-by: Smittyvb <me@smitop.com>
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
8677: Return ServerNotInitialized according to the spec r=kjeremy a=kjeremy
According to the spec we should return ServerNotInitialized if the server is waiting for an initialize request and something else comes in.
Upgrading to lsp-server 0.5.1 will do this and retry until the initialize request comes in.
Fixes#8581
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
According to the spec we should return ServerNotInitialized if the server is waiting for an initialize request and something else comes in.
Upgrading to lsp-server 0.5.1 will do this and retry until the initialize request comes in.
Fixes#8581
8617: Add option to opt out of smaller font size for inlay hints. r=SomeoneToIgnore a=jmederosalvarado
As requested on issue #6883 this PR provides an option for users to opt out of the smaller font size for inlay hints. Part of #6883.
Co-authored-by: Jorge Mederos Alvarado <jmederosalvarado@gmail.com>
At the moment,the popup is just a bazillion of Cargo's "Compiling this\nCompiling that",
which is not that useful.
--quiet still displays error, which is what we needc
8668: Use more cross-platform utc `date` argument r=matklad a=SomeoneToIgnore
Part of https://github.com/rust-analyzer/rust-analyzer/issues/8571
```
$ docker run -it --rm ubuntu:20.04 bash
root@7393d1e7bbad:/# date -u +%Y-%m-%d
2021-04-26
```
```
$ date -u +%Y-%m-%d
2021-04-26
$ uname -a
Darwin alaptop.local 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21 00:07:06 PST 2021; root:xnu-7195.81.3~1/RELEASE_X86_64 x86_64
```
Some of the places where I've change this do not really require it (since macos bin would have failed with `--iso` param also), but I've changed them for consistency.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
8658: Check more carefully for cases where a rename can't be done r=Veykril a=dzhu
Attempting to rename an element of a tuple field would previously replace the type with the new name, which doesn't make sense; now it fails instead.
The check is done in both `prepare_rename` and `rename` so that the case is caught before the user is prompted for a new name. Some other existing failure cases are also now additionally checked in `prepare_rename`.
Closes: #8592
(I threw in some doc edits for a relevant type; of course, I can remove those if the policy here is to be strict about scope of changes within a PR.)
Co-authored-by: Danny Zhu <dzhu@dzhu.us>
Attempting to rename an element of a tuple field would previously
replace the type with the new name, which doesn't make sense; now it
fails instead.
The check is done in both `prepare_rename` and `rename` so that the case
is caught before the user is prompted for a new name. Some other
existing failure cases are also now additionally checked in
`prepare_rename`.
