Conjecture: it's impossible to use hir::Path *correctly* from an IDE.
I am not entirely sure about this, and we might need to add it back at
some point, but I have to arguments that convince me that we probably
won't:
* `hir::Path` has to know about hygiene, which an IDE can't set up
properly.
* `hir::Path` lacks identity, but you actually have to know identity
to resolve it correctly
5637: SSR: Matching trait associated constants, types and functions r=matklad a=davidlattimore
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.
Co-authored-by: David Lattimore <dml@google.com>
5553: Add fix ranges for diagnostics r=matklad a=SomeoneToIgnore
A follow-up of https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Less.20red.20in.20the.20code
Now diagnostics can apply fixes in a range that's different from the range used to highlight the diagnostics.
Previous logic did not consider the fix range, having both ranges equal, which could cause a lot of red noise in the editor.
Now, the fix range gets used with the fix, the diagnostics range is used for everything else which allows to improve the error highlighting.
before:
<img width="191" alt="image" src="https://user-images.githubusercontent.com/2690773/88590727-df9a6a00-d063-11ea-97ed-9809c1c5e6e6.png">
after:
<img width="222" alt="image" src="https://user-images.githubusercontent.com/2690773/88590734-e1fcc400-d063-11ea-9b7c-25701cbd5352.png">
`MissingFields` and `MissingPatFields` diagnostics now have the fix range as `ast::RecordFieldList` of the expression with an error (as it was before this PR), and the diagnostics range as a `ast::Path` of the expression, if it's present (do you have any example of `ast::Expr::RecordLit` that has no path btw?).
The rest of the diagnostics have both ranges equal, same as it was before this PR.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
4743: Add tracking of packed repr, use it to highlight unsafe refs r=matklad a=Nashenas88
Taking a reference to a misaligned field on a packed struct is an
unsafe operation. Highlight that behavior. Currently, the misaligned
part isn't tracked, so this highlight is a bit too aggressive.
Fixes#4600
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
Co-authored-by: Paul Daniel Faria <nashenas88@users.noreply.github.com>
Co-authored-by: Paul Daniel Faria <paulf@pop-os.localdomain>
5699: Fix clippy warnings r=matklad a=popzxc
Currently clippy spawns a bunch of warnings on the `rust-analyzer` project. Nothing critical, but easy to fix, so I guess it won't harm.
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
Without this users have no clue why flycheck fails to run.
This is what is printed to the output channel:
```
[ERROR rust_analyzer::main_loop] cargo check failed: Cargo watcher failed,the command produced no valid metadata (exit code: ExitStatus(ExitStatus(25856)))
```
I stumbled with this figuring out that rust-analyzer adds `--all-features` which is not intended
for some crates in the workspace (e.g. they have mutually-exclusive features.
Having the command rust-analyzer ran should help a lot
Taking a reference to a misaligned field on a packed struct is an
unsafe operation. Highlight that behavior. Currently, the misaligned
part isn't tracked, so this highlight is a bit too aggressive.
5692: Add support for extern crate r=jonas-schievink a=Nashenas88
This adds syntax highlighting, hover and goto def functionality for extern crate.
Fixes#5690
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
5693: Fix no inlay hints / unresolved tokens until manual edit to refresh r=jonas-schievink a=Veetaha
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/5349
Now we return ContentModified during the workspace loading. This signifies the language
client to retry the operation (i.e. the client will
continue polling the server while it returns ContentModified).
I believe that there might be cases of overly big projects where the backoff
logic we have setup in `sendRequestWithRetry` (which we use for inlay hints)
might bail too early (currently the largest retry standby time is 10 seconds).
However, I've tried on one of my project with 500+ dependencies and it is still enough.
Here are the examples before/after the change (the gifs are quite lengthy because they show testing rather large cargo workspace).
<details>
<summary>Before</summary>
Here you can see that the client receives empty array of inlay hints and does nothing more.
Same applies to semantic tokens. The client receives unresolved tokens and does nothing more.
The user needs to do a manual edit to refresh the editor.
</details>
<details>
<summary>After</summary>
Here the server returns ContentModified, so the client periodically retries the requests and eventually receives the wellformed response.
</details>
Co-authored-by: Veetaha <veetaha2@gmail.com>
5414: Fix test code lens r=jonas-schievink a=avrong
Closes#5217
The implementation is quite similar to #4821. Maybe we should somehow deal with duplicated code.
Also, both of these requests introduce some unclear behavior. I'm not sure how to process this, therefore asking for advice. Examples are below.
<img width="286" alt="image" src="https://user-images.githubusercontent.com/6342851/87713209-83595f80-c7b2-11ea-8c0f-a12e7571e7df.png">
Co-authored-by: Aleksei Trifonov <avrong@avrong.me>
No we return ContentModified during the workspace loading. This signifies the language
client to retry the operation (i.e. the client will
continue polling the server while it returns ContentModified).
I believe that there might be cases of overly big projects where the backoff
logic we have setup in `sendRequestWithRetry` (which we use for inlay hints)
might bail too early (currently the largest retry standby time is 10 seconds).
However, I've tried on one of my project with 500+ dependencies and it is still enough.
5684: Semantic highlighting for unsafe union field access r=jonas-schievink a=Nashenas88
This change adds support for unions in inference and lowering, then extends on that to add the unsafe semantic modifier on field access only. The `is_possibly_unsafe` function in `syntax_highlighting.rs` could be extended to support fns and static muts so that their definitions are not highlighted as unsafe, but only their usage.
Also, each commit of this PR updates the tests. By reviewing the files by commit, it's easy to see how the changes in the code affected the tests.
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
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>
`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.
Note that `for` type is rust-analyzer's own invention.
Both the reference and syn allow `for` only for fnptr types, and we
allow them everywhere. This needs to be checked with respect to type
bounds grammar...
The TypeRef name comes from IntelliJ days, where you often have both
type *syntax* as well as *semantical* representation of types in
scope. And naming both Type is confusing.
In rust-analyzer however, we use ast types as `ast::Type`, and have
many more semantic counterparts to ast types, so avoiding name clash
here is just confusing.
5596: Add checkOnSave.noDefaultFeatures and correct, how we handle some cargo flags. r=clemenswasser a=clemenswasser
This PR adds the `rust-analyzer.checkOnSave.noDefaultFeatures` option
and fixes the handling of `cargo.allFeatures`, `cargo.noDefaultFeatures` and `cargo.features`.
Fixes: #5550
Co-authored-by: Clemens Wasser <clemens.wasser@gmail.com>
