bors [Tue, 2 Aug 2022 19:50:01 +0000 (19:50 +0000)]
Auto merge of #12837 - DorianListens:dscheidt/generate-enum-data, r=Veykril
feat: support associated values in "Generate Enum Variant" assist
This change adds support for associated values to the "Generate Enum Variant" assist.
I've split the implementation out into 4 steps to make code review easier:
- Add "add_variant" support to the structural ast editing system in `edit_in_place`
- Migrate `generate_enum_variant` to use structural ast editing instead of string manipulation
- Support tuple fields
- Support record fields
Please let me know if I should leave the commits as-is, or squash before merging.
bors [Tue, 2 Aug 2022 14:08:56 +0000 (14:08 +0000)]
Auto merge of #12880 - palango:while-fixup, r=Veykril
Add syntax fixup for while loops
Part of https://github.com/rust-lang/rust-analyzer/issues/12777
This is a first iteration to gather some feedback. In particular I'm not sure if the curly braces should be added here, but I couldn't get the test to work without them. Any hints welcome!
bors [Mon, 1 Aug 2022 10:12:59 +0000 (10:12 +0000)]
Auto merge of #12918 - lowr:fix/doctest-names, r=Veykril
fix: remove whitespaces from doctest names
When rustdoc runs doctests, it removes whitespaces from the tests' path ([code](https://github.com/rust-lang/rust/blob/25bb1c13bd472b75ceebee3b8dcf4dcbc431a8be/src/librustdoc/doctest.rs#L951)). See https://github.com/rust-lang/rust/pull/89422 for details.
Interestingly enough, "Run doctest" has been working without much problem even though rust-analyzer hasn't followed the change. This is because cargo passes the test name to rustdoc via `--test-args` option, and then rustdoc [splits it by whitespace](https://github.com/rust-lang/rust/blob/25bb1c13bd472b75ceebee3b8dcf4dcbc431a8be/src/librustdoc/config.rs#L513-L514); the last element of the split test name **always** matches the test name that rustdoc generates.
However, it may run other tests unexpectedly (to be precise, this has long since been a thing because of the split). Consider the following example:
When you "Run doctest" either of the two, rustdoc considers "U>" one of the test specs and both doctests are run. This patch fixes it by following rustdoc and removing the whitespace from the doctests' name.
Auto merge of #12915 - lnicola:promote-subtree, r=lnicola
internal: Update `xtask promote` and release instructions
Update `xtask` for the subtree workflow. This doesn't explain how to do a `rust -> RA` sync, since that's definitely more involved, but will probably only happen rarely.
Not too happy with the duplication needed for this, but it is what it is. Completions in path qualifiers will have to be filtered properly still, but its better to show too many completions for this than too few for now.
Auto merge of #12877 - zachs18:inline-def-in-macro, r=zachs18
fix: Insert spaces when inlining a function defined in a macro.
(partially) fixes #12860.
This PR (only) addresses the whitespace issue when inlining functions defined in macros.
Additionally, the indentation/spacing is not ideal, but works, e.g.
```rs
macro_rules! define_function {
() => { fn test_function_macro() {
if let Some(3) = 3i32.checked_add(0) {
println!("3 + 0 == 3");
}
} };
}
define_function!();
fn main() {
test_function_macro();
}
// previously became
// ...
fn main() {
ifletSome(3)=3i32.checked_add(0){println!("3 + 0 == 3");};
}
// now becomes
// ...
fn main() {
if let Some(3) = 3i32.checked_add(0){
println!("3 + 0 == 3");
};
}
```
The `self` -> `this` problem[^this] is (probably?) a separate problem that I am also looking into.
[^this]: As mentioned in [my comment on the above issue](https://github.com/rust-lang/rust-analyzer/issues/12860#issuecomment-1193231766), inlining a method defined in a macro does not properly replace `self` with the new local `this`.
Also downmaps tokens inside deriver helpers to the derive expansion
This does not handle the case where multiple derives make use of the same helper name though, unsure how to tackle that yet.
Auto merge of #12858 - fasterthanlime:proc-macro-srv-bin, r=Veykril
Add `rust-analyzer-proc-macro-srv` binary, use it if found in sysroot
This adds a `bin` crate which simply runs `proc_macro_srv::cli::run()` (it does no CLI argument parsing, nothing).
The intent is to build that crate in Rust CI as part of the `dist::Rustc` component, then ship it in the sysroot: it would probably land in something like `~/.rustup/toolchains/nightly-2022-07-23-x86_64-unknown-linux-gnu/libexec/proc-macro-srv-cli`.
This makes https://github.com/rust-lang/rustup/pull/3022 less pressing. (Instead of teaching RA about rustup components, we simply teach it to look in the sysroot via `rustc --print sysroot`. If it can't find `proc-macro-srv-cli`, it falls back to its own `proc-macro` subcommand).
This is closely related to https://github.com/rust-lang/rust-analyzer/issues/12803 (but doesn't close it yet).
Things to address now:
* [ ] What should the binary be named? What should the crate be named? We can pick different names with `[bin]` in the `Cargo.toml`
Things to address later:
* Disable the "multi ABI compatibility scheme" when building that binary in Rust CI (that'll probably happen in `rust-lang/rust`)
* Teaching RA to look in the sysroot
Things to address much, much later:
* Is JSON a good fit here
* Do we want to add versioning to future-proof it?
* Other bikesheds
When built with `--features sysroot` on `nightly-2022-07-23-x86_64-unknown-linux-gnu`, the binary is 7.4MB. After stripping debuginfo, it's 2.6MB. When compressed to `.tar.xz`, it's 619KB.
In a Zulip discussion, `@jyn514` and `@Mark-Simulacrum` seemed to think that those sizes weren't a stopper for including the binary in the rustc component, even before we shrink it down further.
Auto merge of #12871 - fasterthanlime:sync-from-rust-2, r=Veykril
Sync from `rust-lang/rust`
This is the first subtree sync PR from `rust-lang/rust` to `rust-lang/rust-analyzer`, made by following the instructions at: https://doc.rust-lang.org/nightly/clippy/development/infrastructure/sync.html#performing-the-sync-from-rust-langrust-to-clippy
It includes all the commits that were made in:
* https://github.com/rust-lang/rust/pull/99603
(And that were reviewed ahead of time by `@Veykril` + `@lnicola)`
Auto merge of #12856 - Veykril:multi-proc-srv, r=Veykril
feat: Spawn a proc-macro-srv instance per workspace
cc https://github.com/rust-lang/rust-analyzer/issues/12855
The idea is to have each server be spawned with the appropriate toolchain, that way workspaces with differing toolchains shouldn't suffer from proc-macro abi mismatches.
Auto merge of #12863 - lowr:fix/missing-fields-on-destructuring-assignment, r=Veykril
Fix missing fields check on destructuring assignment
Fixes #12838
When checking if the record literal in question is an assignee expression or not, the new fn `is_assignee_record_literal` iterates over its ancestors until it is sure. This isn't super efficient, as we don't cache anything and does the iteration for every record literal during missing fields check. Alternatively, we may want to have a field like `assignee` on `hir_def::Expr::{RecordLit, Array, Tuple, Call}` to tell if it's an assignee expression, which would be O(1) when checking later but have some memory overhead for the field.
Auto merge of #12832 - lowr:fix/impl-default-members-no-codegen, r=Veykril
fix: don't replace default members' body
cc #12779, #12821
addresses https://github.com/rust-lang/rust-analyzer/pull/12821#issuecomment-1190157506
`gen_trait_fn_body()` only attempts to implement required trait member functions, so we shouldn't call it for `Implement default members` assist.
This patch also documents the precondition of `gen_trait_fn_body()` and inserts `debug_assert!`, but I'm not entirely sure if the assertions are appropriate.
projects / rust.git / log