Auto merge of #13174 - Veykril:resolver, r=Veykril
Lift out the module scope into a field in the Resolver
A Resolver *always* has a module scope at the end of its scope stack,
instead of encoding this as an invariant we can just lift this scope
out into a field, allowing us to skip going through the scope vec
indirection entirely.
Lift out the module scope into a field in the Resolver
A Resolver *always* has a module scope at the end of its scope stack,
instead of encoding this as an invariant we can just lift this scope
out into a field, allowing us to skip going through the scope vec
indirection entirely.
Auto merge of #13167 - iDawer:exhaustive_patterns, r=Veykril
feat: Implement `feature(exhaustive_patterns)` from unstable Rust
Closes #12753
Recognize Rust's unstable `#![feature(exhaustive_patterns)]` (RFC 1872). Allow omitting visibly uninhabited variants from `match` expressions when the feature is on.
This adjusts match checking to the current implementation of the postponed RFC 1872 in rustc.
Auto merge of #13161 - ChayimFriedman2:pi-is-zero, r=jonas-schievink
fix: Lower float literals with underscores
Fixes #13155 (the problem was the `PI` is defined with `_f64` suffix). `PI` is still truncated, though, because `f64` cannot represent the value with full precision.
We now diagnose invalid `continue` expressions and properly handle things like `async` blocks which prevent labels from resolving further. Cleaned this up since `label_break_value` is on the way to stabilization in rust (🎉 finally) and we weren't handling breaks for blocks properly yet.
bors [Wed, 31 Aug 2022 19:42:53 +0000 (19:42 +0000)]
Auto merge of #13134 - Veykril:proc-highlight, r=Veykril
Highlight namerefs by syntax until proc-macros have been loaded
Usually when loading up a project, once loading is done we start answering highlight requests while proc-macros haven't always been loaded yet, so we start out with showing a lot of unresolved name-refs. After this PR, we'll use syntax based highlighting for those unresolved namerefs until the proc-macros have been loaded.
bors [Wed, 31 Aug 2022 16:09:17 +0000 (16:09 +0000)]
Auto merge of #13156 - Veykril:macro-stmts, r=Veykril
Remove hir::Expr::MacroStmts
This hir expression isn't needed and only existed as it was simpler to
deal with at first as it gave us a direct mapping for the ast version of
the same construct. This PR removes it, properly handling the statements
that are introduced by macro call expressions.
Lukas Wirth [Wed, 31 Aug 2022 14:58:11 +0000 (16:58 +0200)]
Remove hir::Expr::MacroStmts
This hir expression isn't needed and only existed as it was simpler to
deal with at first as it gave us a direct mapping for the ast version of
the same construct. This PR removes it, properly handling the statements
that are introduced by macro call expressions.
bors [Wed, 31 Aug 2022 13:34:43 +0000 (13:34 +0000)]
Auto merge of #13051 - DropDemBits:attrs-and-comments-on-enum-variant, r=jonas-schievink
fix: Only move comments when extracting a struct from an enum variant
Motivating example:
```rs
#[derive(Debug, thiserror::Error)]
enum Error {
/// Some explanation for this error
#[error("message")]
$0Woops {
code: u32
}
}
```
now becomes
```rs
/// Some explanation for this error
#[derive(Debug, thiserror::Error)]
struct Woops{
code: u32
}
#[derive(Debug, thiserror::Error)]
enum Error {
#[error("message")]
Woops(Woops)
}
```
(the `thiserror::Error` derive being copied and the struct formatting aren't ideal, though those are issues for another day)
bors [Wed, 31 Aug 2022 08:28:12 +0000 (08:28 +0000)]
Auto merge of #12793 - lowr:fix/12739, r=Veykril
fix: sort and deduplicate auto traits in trait object types
Fixes #12739
Chalk solver doesn't sort and deduplicate auto traits in trait object types, so we need to handle them ourselves in the lowering phase, just like [`rustc`](https://github.com/rust-lang/rust/blob/880416180b0a9ee1141c07d4d17667edb77daebd/compiler/rustc_typeck/src/astconv/mod.rs#L1487-L1488) and [`chalk-integration`](https://github.com/rust-lang/chalk/blob/master/chalk-integration/src/lowering.rs#L575) do.
Quoting from [the Chalk book](https://rust-lang.github.io/chalk/book/types/rust_types.html#dyn-types):
> Note that -- for this purpose -- ordering of bounds is significant. That means that if you create a `dyn Foo + Send` and a `dyn Send + Foo`, chalk would consider them distinct types. The assumption is that bounds are ordered in some canonical fashion somewhere else.
Also, trait object types with more than one non-auto traits were previously allowed, but are now disallowed with this patch.
bors [Wed, 31 Aug 2022 08:07:26 +0000 (08:07 +0000)]
Auto merge of #13154 - Veykril:ty-mac-expander, r=Veykril
Drop the expander borrow in all control flow paths
The change in https://github.com/rust-lang/rust-analyzer/pull/13123
actually re-uses the RefMut borrow instead of dropping it so we need to
drop it manually where required.
Lukas Wirth [Wed, 31 Aug 2022 08:04:01 +0000 (10:04 +0200)]
Drop the expander borrow in all control flow paths
The change in https://github.com/rust-lang/rust-analyzer/pull/13123
actually re-uses the RefMut borrow instead of dropping it so we need to
drop it manually where required.
Use type information to deduce the correct type for "Replace turbofish with explicit type", even when it is not exactly the same as the turbofish type
I implemented that by checking the expressions' type.
This could probably be implemented better by taking the function's return type and substituting the generic parameter with the provided turbofish, but this is more complicated.
bors [Tue, 30 Aug 2022 13:31:37 +0000 (13:31 +0000)]
Auto merge of #13145 - ChayimFriedman2:unmerge-match-arm, r=jonas-schievink
feat: Add a "Unmerge match arm" assist to split or-patterns inside match expressions
Fixes #13072.
The way I implemented it it leaves the `OrPat` in place even if there is only one pattern now but I don't think something will break because of that, and when more code will be typed we'll parse it again anyway. Removing it (but keeping the child pattern) is hard, I don't know how to do that.
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
projects / rust.git / log