5686: Fix typo in settings description r=kjeremy a=rherrmann
Remove a duplicate word from the description of the `warningsAsHint` setting.
Co-authored-by: Rüdiger Herrmann <ruediger.herrmann@gmx.de>
5679: Account for static mut in missing unsafe diagnostic r=jonas-schievink a=Nashenas88
Accessing or modifying a static mut is an unsafe operation. The "missing unsafe" diagnostic now tracks this.
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
5678: Static mut unsafe semantic highlighting r=jonas-schievink a=Nashenas88
This marks static mutable names as unsafe, since accessing or modifying a static mut is an unsafe operation.
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
5526: Handle semantic token deltas r=kjeremy a=kjeremy
This basically takes the naive approach where we always compute the tokens but save space sending over the wire which apparently solves some GC problems with vscode.
This is waiting for https://github.com/gluon-lang/lsp-types/pull/174 to be merged. I am also unsure of the best way to stash the tokens into `DocumentData` in a safe manner.
Co-authored-by: kjeremy <kjeremy@gmail.com>
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
5639: SSR: Allow `self` in patterns. r=jonas-schievink a=davidlattimore
It's now consistent with other variables in that if the pattern references self, only the `self` in scope where the rule is invoked will be accepted. Since `self` doesn't work the same as other paths, this is implemented by restricting the search to just the current function. Prior to this change (since path resolution was implemented), having self in a pattern would just result in no matches.
Co-authored-by: David Lattimore <dml@google.com>
5664: Fix renamed self module. r=jonas-schievink a=Nashenas88
Fixes#5663
Now `inner_mod` below is properly marked as a `module`.
```rust
use crate::inner::{self as inner_mod};
mod inner {}
```
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
5668: Fix relative path handling for custom rustfmt r=matklad a=matklad
`current_dir` and relative paths to executables works differently on
unix and windows (unix behavior does not make sense), see:
17e30e83a1/src/lib.rs (L295-L324)
The original motivation to set cwd was to make rustfmt read the
correct rustfmt.toml, but that was future proofing, rather than a bug
fix.
So, let's just remove this and see if breaks or fixes more use-cases.
If support for per-file config is needed, we could use `--config-path`
flag.
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
`current_dir` and relative paths to executables works differently on
unix and windows (unix behavior does not make sense), see:
17e30e83a1/src/lib.rs (L295-L324)
The original motivation to set cwd was to make rustfmt read the
correct rustfmt.toml, but that was future proofing, rather than a bug
fix.
So, let's just remove this and see if breaks or fixes more use-cases.
If support for per-file config is needed, we could use `--config-path`
flag.
5658: do not add to `pub use` in assists that insert a use statement r=jonas-schievink a=jbr
closes#5657 , see issue for rationale
Initially I wrote a version of this that changed the signature of `insert_use_statement` to take an `Option<VisibilityKind>` and only add to use statements with the same visibility, but that didn't make sense for any of the current uses of `insert_use_statement` (they all expected private visibility).
Co-authored-by: Jacob Rothstein <hi@jbr.me>
It's now consistent with other variables in that if the pattern
references self, only the `self` in scope where the rule is invoked will
be accepted. Since `self` doesn't work the same as other paths, this is
implemented by restricting the search to just the current function.
Prior to this change (since path resolution was implemented), having
self in a pattern would just result in no matches.
This fixes matching of things like `HashMap::default()` by resolving
`HashMap` instead of `default` (which resolves to `Default::default`).
Same for associated constants and types that are part of a trait
implementation.
However, we still don't support matching calls to trait methods.
