bors [Sun, 28 Aug 2022 09:56:06 +0000 (09:56 +0000)]
Auto merge of #13133 - Veykril:diag-hack, r=Veykril
Move empty diagnostics workaround back into the server
This only touches on the diagnostics in one place instead of multiple as was previously done, since all published diagnostics will go through this code path anyways.
bors [Fri, 26 Aug 2022 16:22:57 +0000 (16:22 +0000)]
Auto merge of #13087 - Veykril:config-update, r=Veykril
Remove auto-config patching from the VSCode client
This was introduced 4 months ago when we drastically changed the config keys. I'd like to remove this given I always felt uneasy doing edits to a users config from within r-a, and by now most if not all users should've swapped to a new enough version of r-a that should've updated their configs.
The extension will continue to work fine even with the outdated keys afterwards since we still do patching server side as well, and that one we'll have to support for quite some more time (if not until a proper 1.0 release where I assume we can allow ourselves some more user facing breakage)
(There also might've been a small bug in here that prevented users with certain outdated keys to prevent them from enabling certain keys for some reason)
bors [Thu, 25 Aug 2022 19:08:57 +0000 (19:08 +0000)]
Auto merge of #13116 - Veykril:nohash, r=Veykril
Make use of NoHash hashing for FileId and CrateId
Both of these are mere integers so there is nothing to hash here.
Ideally we would use this for `la_arena::Idx` too, but that doesn't work due to the orphan rule, and `la_arena` is unfortunately a public library so we can't really do much here... Unless we remove the trait restriction but I'd like not to
Oddly, the leading `|` token does not end up inside the `OR_PAT` node, since `pattern_top_r` consumes it first. This is a preexisting issue in match arms though, so I didn't fix it here.
bors [Tue, 23 Aug 2022 12:39:57 +0000 (12:39 +0000)]
Auto merge of #13084 - Veykril:highlight-config, r=Veykril
Add some more highlighting configurations
The following can be enabled/disabled now in terms of highlighting:
- doc comment injection (enabled by default)
- punctuation highlighting (disabled by default)
- operator highlighting (enabled by default)
- punctuation specialized highlighting (disabled by default)
- operator specialized highlighting (disabled by default)
- macro call bang highlighting (disabled by default)
This PR also changes our `attribute` semantic token type to the `decorator` type which landed upstream (but not yet in lsp-types).
Specialized highlighting is disabled by default, as all clients will have to ship something to map these back to the standard punctuation/operator token (we do this in VSCode via the inheritance mapping for example). This is a lot of maintenance work, and not something every client wants to do, pushing that need to use the user. As this is a rather niche use in the first place this will just be disabled by default.
Punctuation highlighting is disabled by default, punctuation is usually something that can be done by the native syntactic highlighting of the client, so there is no loss in quality. The main reason for this though is that punctuation adds a lot of extra token data that we sent over, a lot of clients struggle with applying this, so disabling this improves the UX for a lot of people. Note that we still highlight punctuations with special meaning as that special entity, (the never type `!` will still be tagged as a builtin type if it occurs as such)
Separate highlighting of the macro call bang `!` is disabled by default, as I think people actually didn't like that change that much, though at the same time I feel like not many people even noticed that change (I prefer it be separate, but that's not enough reason for it to be enabled by default I believe :^) )
cc https://github.com/rust-lang/rust-analyzer/issues/12783 https://github.com/rust-lang/rust-analyzer/issues/13066
bors [Tue, 23 Aug 2022 07:53:36 +0000 (07:53 +0000)]
Auto merge of #12976 - tjdevries:scip, r=Veykril
feat: emit SCIP from rust-analyzer
hi rust-analyzer team
I'm one of the engineers at Sourcegraph (and have done a few small changes related to the LSIF work done in rust-analyzer). Recently, we've moved to a new protocol as the primary way to interact with Sourcegraph (LSIF is still possible to upload, so existing jobs will not stop working any time soon). This new protocol is SCIP (I linked a blog post below with more information).
I've implemented SCIP support (based largely on the existing LSIF support). In addition to supporting the existing features that `rust-analyzer`'s LSIF support does, this PR adds the ability to move between crates on sourcegraph.com. So if both your project and a dependency are indexed, you would be able to hop to the particular version and view the source code. I'd be happy to record a demo of that on my local instance if you're interested.
There are a few TODO's left in the code (some that you might have insights on) which I'm happy to fix in this PR, but I just wanted to open this up for discussion first.
bors [Mon, 22 Aug 2022 14:00:23 +0000 (14:00 +0000)]
Auto merge of #13021 - N3xed:fix-gat-panics, r=flodiebold
fix: Fix panics on GATs involving const generics
This workaround avoids constant crashing of rust analyzer when using GATs with const generics,
even when the const generics are only on the `impl` block.
The workaround treats GATs as non-existing if either itself or the parent has const generics and
removes relevant panicking code-paths.
bors [Sun, 21 Aug 2022 12:21:33 +0000 (12:21 +0000)]
Auto merge of #13074 - lowr:fix/method-resolution-with-impl-predicate, r=lowr
Consider bounds on inherent impl in method resolution
There are three type-related things we should consider in method resolution: `Self` type, receiver type, and impl bounds. While we check the first two and impl bounds on trait impls, we've been ignoring the impl bounds on inherent impls. With this patch rust-analyzer now takes them into account and is able to select the appropriate inherent method.
bors [Fri, 19 Aug 2022 10:57:02 +0000 (10:57 +0000)]
Auto merge of #13041 - DorianListens:dscheidt/gen-fn-self-assoc-2, r=Veykril
feat: Generate static method using Self::assoc() syntax
This change improves the `generate_function` assist to support generating static methods/associated functions using the `Self::assoc()` syntax. Previously, one could generate a static method, but only when specifying the type name directly (like `Foo::assoc()`). After this change, `Self` is supported as well as the type name.
bors [Fri, 19 Aug 2022 07:23:01 +0000 (07:23 +0000)]
Auto merge of #13064 - Veykril:rustfmt-err, r=Veykril
Log rustfmt parsing errors as warnings
We unconditionally pass an edition parameter to rustfmt, for some crates
this might fail rustfmt so instead of swallowing the error, at least Log
it on a level that is logged by default so users won't be completely
confused about it.
See for context https://github.com/rust-lang/rust-analyzer/issues/10209
Lukas Wirth [Fri, 19 Aug 2022 07:19:02 +0000 (09:19 +0200)]
Log rustfmt parsing errors as warnings
We unconditionally pass an edition parameter to rustfmt, for some crates
this might fail rustfmt so instead of swallowing the error, at least Log
it on a level that is logged by default so users won't be completely
confused about it.
See for context https://github.com/rust-lang/rust-analyzer/issues/10209
bors [Thu, 18 Aug 2022 08:02:37 +0000 (08:02 +0000)]
Auto merge of #13036 - sancho20021:10881-inline_type_alias_uses, r=Veykril
feat: Add an assist for inlining all type alias uses
## Description
`inline_type_alias_uses` assist tries to inline all selected type alias occurrences.
### Currently
Type alias used in `PathType` position are inlined.
### Not supported
- Removing type alias declaration if all uses are inlined.
- Removing redundant imports after inlining all uses in the file.
- Type alias not in `PathType` position, such as:
- `A::new()`
- `let x = A {}`
- `let bits = A::BITS`
- etc.
bors [Thu, 18 Aug 2022 07:54:10 +0000 (07:54 +0000)]
Auto merge of #13045 - DorianListens:dscheidt/run-test-mod-outside, r=Veykril
feat: Run test mod from anywhere in parent file
The "Run" feature of rust-analyzer is super useful, especially for running
individual tests or test-modules during development.
One common pattern in rust development is to develop tests in the same file as
production code, inside a module (usually called `test` or `tests`) marked with
`#[cfg(test)]`. Unforunately, this pattern is not well supported by r-a today,
as a test module won't show up as a runnable unless the cursor is inside it.
In my experience, it is quite common to want to run the tests associated with
some production code immediately after editing it, not only after editing the
tests themselves. As such it would be better if test modules were available
from the "Run" menu even when the cursor is outside the test module.
This change updates the filtration logic for runnables in
`handlers::handle_runnables` to special case `RunnableKind::TestMod`, making
test modules available regardless of the cursor location. Other `RunnableKind`s
are unnaffected.
bors [Thu, 18 Aug 2022 07:37:47 +0000 (07:37 +0000)]
Auto merge of #12982 - jridgewell:into_future, r=Veykril
Implement IntoFuture type inference
One of my projects is using [IntoFuture](https://doc.rust-lang.org/std/future/trait.IntoFuture.html) to make our async code a little less verbose. However, rust-analyzer can't infer the output type of an await expression if the value uses `IntoFuture` to convert into another type. So we're getting `{unknown}` types everywhere since switching.
`foo.await` itself [desugars](https://github.com/rust-lang/rust/blob/e4417cf020fbcd6182c11637bc6b8694434bd81a/compiler/rustc_ast_lowering/src/expr.rs#L644-L658) into a `match into_future(foo) {}`, with every `Future` impl getting a [default](https://github.com/rust-lang/rust/blob/e4417cf020fbcd6182c11637bc6b8694434bd81a/library/core/src/future/into_future.rs#L131-L139) `IntoFuture` implementation. I'm not sure if we want to disable the old `future_trait` paths, since this only recently [stabilize](https://github.com/rust-lang/rust/pull/98718).
bors [Thu, 18 Aug 2022 07:29:16 +0000 (07:29 +0000)]
Auto merge of #13049 - lowr:fix/bare-dyn-assoc-type, r=Veykril
fix: resolve associated types of bare dyn types
Fixes #13031
We've been dropping the associated type bindings of trait object types that were written without the `dyn` keyword. This patch reuses the lowering logic for `TypeRef::DynTrait` so the associated type bindings are properly lowered.
Dorian Scheidt [Wed, 17 Aug 2022 16:57:14 +0000 (11:57 -0500)]
feat: Run test mod from anywhere in parent file
The "Run" feature of rust-analyzer is super useful, especially for running
individual tests or test-modules during development.
One common pattern in rust development is to develop tests in the same file as
production code, inside a module (usually called `test` or `tests`) marked with
`#[cfg(test)]`. Unforunately, this pattern is not well supported by r-a today,
as a test module won't show up as a runnable unless the cursor is inside it.
In my experience, it is quite common to want to run the tests associated with
some production code immediately after editing it, not only after editing the
tests themselves. As such it would be better if test modules were available
from the "Run" menu even when the cursor is outside the test module.
This change updates the filtration logic for runnables in
`handlers::handle_runnables` to special case `RunnableKind::TestMod`, making
test modules available regardless of the cursor location. Other `RunnableKind`s
are unnaffected.
bors [Wed, 17 Aug 2022 14:59:02 +0000 (14:59 +0000)]
Auto merge of #13044 - dzvon:fix-typo, r=Veykril
fix: a bunch of typos
This PR will fix some typos detected by [typos].
There are also some other typos in the function names, variable names, and file
names, which I leave as they are. I'm more certain that typos in comments
should be fixed.
Dezhi Wu [Wed, 17 Aug 2022 13:44:58 +0000 (21:44 +0800)]
fix: a bunch of typos
This PR will fix some typos detected by [typos].
There are also some other typos in the function names, variable names, and file
names, which I leave as they are. I'm more certain that typos in comments
should be fixed.
bors [Wed, 17 Aug 2022 09:55:14 +0000 (09:55 +0000)]
Auto merge of #13034 - lowr:fix/regression-from-12993, r=lowr
fix: escape keywords used as names in earlier editions
Fixes #13030
There are keywords in Rust 2018+ that you can use as names without escaping when your crate is in Rust 2015 e.g. "try". We need to be consistent on how to keep track of the names regardless of how they are actually written in each crate. This patch attempts at it by taking such names into account and storing them uniformly in their escaped form.
projects / rust.git / log