bors[bot] [Mon, 7 Dec 2020 16:21:51 +0000 (16:21 +0000)]
Merge #6745
6745: Some more proc macro cleanups r=jonas-schievink a=jonas-schievink
* Remove `ProcMacroClient::dummy` and just use `Option<ProcMacroClient>` instead
* Remember the type of proc macros (later allows us to reject using an incorrect macro type)
* Prepare a few internals for procedural attribute macros
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
bors[bot] [Mon, 7 Dec 2020 15:12:53 +0000 (15:12 +0000)]
Merge #6743
6743: Don't insert blank lines between doc attributes r=Veykril a=Veykril
Fixes #6742.
Doc attributes should be concatenated via a single linebreak as written in the [rustdoc book](https://doc.rust-lang.org/nightly/rustdoc/the-doc-attribute.html).
Also changed the loop to use an iterator to get rid of the `docs.trim_end_matches("\n\n").to_owned()` part using `Itertools::intersperse`.
Basically the counterpart to `replace_if_let_with_match`, I personally sometimes want to replace matches like
```rust
match foo {
pat => expr,
_ => (),
}
```
into the corresponding
```rust
if let pat = foo {
expr
}
```
which is the main reasoning behind this.
I put this into the same file as `replace_if_let_with_match` because the are complementing each other and I would probably rename the file to something like `replace_if_let_match` but I didn't do that for now because I was unsure whether git would still view this as a rename or not due to the amount of changes in the file so that the diff is still properly visible for now.
bors[bot] [Sun, 6 Dec 2020 16:00:03 +0000 (16:00 +0000)]
Merge #6733
6733: Update attributes completion list r=jonas-schievink a=Veykril
Might be nice to have them grouped for readability/maintainability similar to how the [reference](https://doc.rust-lang.org/reference/attributes.html#built-in-attributes-index) does it but that would require the use of a `OnceCell` for sorting the entries back after construction.
bors[bot] [Sun, 6 Dec 2020 13:26:54 +0000 (13:26 +0000)]
Merge #6734
6734: Emit additional diagnostics for hints/help/etc r=lnicola a=jonas-schievink
This makes rust-analyzer diagnostics match native rustc diagnostics in the terminal more closely. Unfortunately all of this is a bodge, since we already provide this information to the client in the form of `DiagnosticRelatedInformation`, but at least VS Code chooses such a poor UI for these that they don't help much, as evidenced [here](https://twitter.com/yaahc_/status/1335297260444250112) and in https://github.com/rust-lang/rust/issues/79741.
This PR papers over these client UI problems by taking the `DiagnosticRelatedInformation` and turning each one into its own hint-level diagnostic, which makes it show up in the source code. Quick fixes are attached to all resulting diagnostics, which makes them more discoverable.
bors[bot] [Fri, 4 Dec 2020 18:39:04 +0000 (18:39 +0000)]
Merge #6724
6724: Fix `diagnostics` subcommand, look at all modules r=jonas-schievink a=jonas-schievink
The `diagnostics` subcommand used to only compute diagnostics for `lib.rs` / the root module of all workspace crates. This fixed it and makes it look at every module.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
bors[bot] [Fri, 4 Dec 2020 17:44:37 +0000 (17:44 +0000)]
Merge #6723
6723: Use correct, full substs for self type in impl r=flodiebold a=flodiebold
Without arbitrary self types, the self type could never refer to the method type parameters, so this wasn't a problem; but with arbitrary self types, it can.
This fixes the crash from #6668; but it doesn't make method resolution work for these methods.
Florian Diebold [Fri, 4 Dec 2020 17:41:37 +0000 (18:41 +0100)]
Use correct, full substs for self type in impl
Without arbitrary self types, the self type could never refer to the method type
parameters, so this wasn't a problem; but with arbitrary self types, it can.
This fixes the crash from #6668; but it doesn't make method resolution work for
these methods.
Diagnostics inside proc macros are currently incorrectly placed at their original offset, but inside the containing file. This fixes that, by allowing the creation of `ExpansionInfo` from non-`macro_rules!` macro invocations.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
bors[bot] [Wed, 2 Dec 2020 13:25:54 +0000 (13:25 +0000)]
Merge #6698
6698: Attach macro expansion errors to the right file r=jonas-schievink a=jonas-schievink
Previously it attached them to the result of the macro expansion (or, if no result was produced, to the file containing the invocation). Always use the file containing the invocation.
This doesn't seem to have any observable difference, but seems better in theory.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
bors[bot] [Sun, 29 Nov 2020 20:03:44 +0000 (20:03 +0000)]
Merge #6665
6665: Support self in reference search r=matklad a=Veykril
The approach here is simply checking the descendants of the function body for `PathExpr` then checking whether it only contains a single `self` `PathSegment`, this is to prevent us from picking up `self` tokens from local `UseTree`s.