This changes the generate getter assist to not say "a reference to" in the documentation stub if the type is Copy, as the getter does not return a reference.
11054: fix#11049 by removing double trimming r=Veykril a=Heinenen
The `unwrap_trivial_block()` removes the braces around trivial blocks (as the name suggests). This violates the precondition of `update_expr_string()` which removes the first and the last non-whitespace character and thus expects braces to still exist around all blocks.
Co-authored-by: ucrhh <ucrrh@sutdent.kit.edu>
11053: feat: Publish platform-specific Code VSIXes r=me a=lnicola
Closes#10483
CC #10371
Some notes:
- we still build a plain VSIX, just in case
- we build the extension on every platform to make the release workflow arguably cleaner
- the Windows VSIX includes the PDB (but let's leave #10371 open until we change the Windows stand-alone release to a ZIP file)
- `npm` doesn't run if started from `xtask`, possibly something related to path mapping; I moved the `npm` calls outside, but..
- the `Patch` thingy doesn't work any more, so you'll end up with a dirty `package.json` of you run `cargo xtask --client-patch-version`; I don't think we should block on this
- there's an untested Alpine build; for better or worse, we special-case `musl` distros as `alpine`
- I tested this as much as I could, but not the publishing and nightly updates
- you can find some sample artifacts under https://github.com/lnicola/rust-analyzer/releases
- we can now run the server from the install location (is Code planning to switch to compressed extensions?), except on NixOS
- Code lets you install a VSIX for the wrong platform (with the results one would expect)
- I don't know what happens if we try to publish a VSIX without a target
This is a relatively risky, but we'll probably have to take our chances with it.
r? `@rust-analyzer/review`
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
11047: internal: Prepare Code extension for bundling r=lnicola a=lnicola
CC #10483
This is slightly ugly, but we'll be able to clean it up after ripping the download parts (unless we decide to temporarily drop support for the nightlies).
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
11043: fix: fix incorrect mismatched argument count diagnostic with `std::arch` functions r=jonas-schievink a=jonas-schievink
Adds basic support for `#[rustc_legacy_const_generics]`.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10009
Full support would involve actually checking call arguments against the right expected types.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11030: Add comma for "move if to guard" r=Veykril a=weirane
As I mentioned in #11017, there is a little issue in the implementation for if branch. This code
```rust
let y = match 92 {
x => {
if x == 0 {$0
false
}
}
_ => true,
};
```
will be transformed to
```rust
let y = match 92 {
x if x == 0 => false
_ => true,
};
```
a comma is missing after the false. I moved the fix from the code handling else branch to above.
Co-authored-by: Wang Ruochen <wrc@ruo-chen.wang>
11031: minor: Set `MACOSX_DEPLOYMENT_TARGET` to 10.15 to improve compat r=lnicola a=lnicola
Since GitHub (and also us, explicitly) switched the `macos-latest` runners to 11, let's try to bring back support for 10.15.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
11017: Support "move if to guard" with an else branch r=Veykril a=weirane
Support the assist `move_arm_cond_to_match_guard` when there is an else branch.
I have two questions:
1. How to indent the first line of a match arm? `matcharm.indent()` doesn't seem to work. so I hard coded four spaces here:
95a0de85d5/crates/ide_assists/src/handlers/move_guard.rs (L162-L163)
2. I find a little issue in the original implementation, this code
```rust
let y = match 92 {
x => {
if x == 0 {$0
false
}
}
_ => true,
};
```
will be transformed to
```rust
let y = match 92 {
x if x == 0 => false
_ => true,
};
```
a comma is missing after the `false`. Should I also fix that? Or this can go in a separate PR.
Closes#10997.
Co-authored-by: Wang Ruochen <wrc@ruo-chen.wang>