5004: Fix panic in split/merge import assists r=matklad a=lnicola
Fixes#4368#4905
Not sure if this is the best solution here. Maybe the `make` functions should be fallible? We generally seem to be playing whack-a-mole with panics in assists, although most of them are `unwrap`s in the assist code.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
5002: Fix underflow panic when doctests are at top of file r=Nashenas88 a=Nashenas88
While debugging a comment at the top of a test string, I discovered that the offset calculations could underflow and panic. This only seemed to occur in tests, I assume because it's running a debug mode. The wrapping is quickly fixed later on in release mode, which is why this seems to have gone unnoticed. The new checks ensure the value is always positive or zero.
Co-authored-by: Paul Daniel Faria <nashenas88@users.noreply.github.com>
4999: SSR: Allow matching of whole macro calls r=matklad a=davidlattimore
Matching within macro calls is to come later and matching of macro calls within macro calls later still.
Co-authored-by: David Lattimore <dml@google.com>
5000: Remove RelativePathBuf from fixture r=matklad a=matklad
The paths in fixture are not really relative (the default one is
`/main.rs`), so it doesn't make sense to use `RelativePathBuf` here.
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
4900: Self variant enum res fix r=BGluth a=BGluth
Fixes#4789.
This is my first PR for this project, so it's probably worth giving it an extra close look.
A few things that I wasn't sure about:
- Is `resolve_path` really the best place to perform this check? It seemed like a natural place, but perhaps there's a better place?
- When handling the new variant `PathResolution::VariantDef`, I couldn't see an obvious variant of `TypeNs` to return in `in_type_ns` for Unions and Structs.
Co-authored-by: BGluth <gluthb@gmail.com>
4921: Allow SSR to match type references, items, paths and patterns r=davidlattimore a=davidlattimore
Part of #3186
Co-authored-by: David Lattimore <dml@google.com>
4947: Replace `impls_in_trait` query with smarter use of `CrateImplDefs` r=matklad a=jonas-schievink
`impls_in_trait` was allocating a whopping ~400 MB of RAM when running analysis-stats on r-a itself.
Remove it, instead adding a query that computes a summary `CrateImplDefs` map for all transitive dependencies. This can probably still be made more efficient, but this already reduces the peak memory usage by 25% without much performance impact on analysis-stats.
**Before**:
```
Total: 34.962107188s, 2083mb allocated 2141mb resident
422mb ImplsForTraitQuery (deps)
250mb CrateDefMapQueryQuery
147mb MacroArgQuery
140mb TraitSolveQuery (deps)
68mb InferQueryQuery (deps)
62mb ImplDatumQuery (deps)
```
**After**:
```
Total: 35.261100358s, 1520mb allocated 1569mb resident
250mb CrateDefMapQueryQuery
147mb MacroArgQuery
144mb TraitSolveQuery (deps)
68mb InferQueryQuery (deps)
61mb ImplDatumQuery (deps)
45mb BodyQuery
45mb ImplDatumQuery
```
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
4958: Infer FnSig via Fn traits r=flodiebold a=adamrk
Addresses https://github.com/rust-analyzer/rust-analyzer/issues/4481.
When inferring types check if the callee implements one of the builtin `Fn` traits. Also autoderef the callee before trying to figure out it's `FnSig`.
Co-authored-by: adamrk <ark.email@gmail.com>
When referring to an associated type of a super trait, we used the substs of the
subtrait. That led to the #4931 crash if the subtrait had less parameters, but
it could also lead to other incorrectness if just the order was different.
Fixes#4931.
4851: Add quickfix to add a struct field r=TimoFreiberg a=TimoFreiberg
Related to #4563
I created a quickfix for record literals first because the NoSuchField diagnostic was already there.
To offer that quickfix for FieldExprs with unknown fields I'd need to add a new diagnostic (or create a `NoSuchField` diagnostic for those cases)
I think it'd make sense to make this a snippet completion (to select the generated type), but this would require changing the `Analysis` API and I'd like some feedback before I touch that.
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
4937: Allow overriding rust-analyzer display version r=matklad a=oxalica
The build script invokes `git` for version information which is displayed when rust-analyzer is called with `--version`. But in build environment without `git` or when the source code is not a git repo, there's no way to manually specify the version information.
This patch respects environment variable ~`REV`~ `RUST_ANALYZER_REV` in compile time for overriding.
Related: https://github.com/NixOS/nixpkgs/pull/90976
Co-authored-by: oxalica <oxalicc@pm.me>
The task of `partition` function is to bin the flat list of paths into
disjoint filesets. Ideally, it should be incremental -- each new file
should be added to a specific fileset.
However, preliminary measurnments show that it is actually fast enough
if we just optimize this to use a binary search instead of a linear
scan.
4930: Avoid all unchecked indexing in match checking r=flodiebold a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/4416, but replaces it with a false positive.
r? @flodiebold
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
4903: Add highlighting support for doc comments r=matklad a=Nashenas88
The language server protocol includes a semantic modifier for documentation. This change exports that modifier for doc comments so users can choose to highlight them differently compared to regular comments.
Example:
<img width="375" alt="Screen Shot 2020-06-16 at 10 34 14 AM" src="https://user-images.githubusercontent.com/1673130/84788271-f6599580-afbc-11ea-96e5-7a0215da620b.png">
CC @woody77
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
4934: Remove special casing for library symbols r=matklad a=matklad
We might as well handle them internally, via queries.
I am not sure, but it looks like the current LibraryData setup might
even predate salsa? It's not really needed and creates a bunch of
complexity.
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
We might as well handle them internally, via queries.
I am not sure, but it looks like the current LibraryData setup might
even predate salsa? It's not really needed and creates a bunch of
complexity.
4927: Better encapsulate reverse-mapping of files to cargo targets r=matklad a=matklad
We need to find a better way to do it...
CrateGraph by itself is fine, CargoWorkspace as well, but the mapping
between the two seems arbitrary...
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
4913: Remove debugging code for incremental sync r=matklad a=lnicola
4915: Inspect markdown code fences to determine whether to apply syntax highlighting r=matklad a=ltentrup
Fixes#4904
4916: Warnings as hint or info r=matklad a=GabbeV
Fixes#4229
This PR is my second attempt at providing a solution to the above issue. My last PR(#4721) had to be rolled back(#4862) due to it overriding behavior many users expected. This PR solves a broader problem while trying to minimize surprises for the users.
### Problem description
The underlying problem this PR tries to solve is the mismatch between [Rustc lint levels](https://doc.rust-lang.org/rustc/lints/levels.html) and [LSP diagnostic severity](https://microsoft.github.io/language-server-protocol/specification#diagnostic). Rustc currently doesn't have a lint level less severe than warning forcing the user to disable warnings if they think they get to noisy. LSP however provides two severitys below warning, information and hint. This allows editors like VSCode to provide more fine grained control over how prominently to show different diagnostics.
Info severity shows a blue squiggly underline in code and can be filtered separately from errors and warnings in the problems panel.
Hint severity doesn't show up in the problems panel at all and only show three dots under the affected code or just faded text if the diagnostic also has the unnecessary tag.
### Solution
The solution provided by this PR allows the user to configure lists of of warnings to report as info severity and hint severity respectively. I purposefully only convert warnings and not errors as i believe it's a good idea to have the editor show the same severity as the compiler as much as possible.
### Open questions
#### Discoverability
How do we teach this to new and existing users? Should a section be added to the user manual? If so where and what should it say?
#### Defaults
Other languages such as TypeScript report unused code as hint by default. Should rust-analyzer similarly report some problems as hint/info by default?
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
Co-authored-by: Gabriel Valfridsson <gabriel.valfridsson@gmail.com>
Anchoring to the SourceRoot wont' work if the path is absolute:
#[path = "/tmp/foo.rs"]
mod foo;
Anchoring to a file will.
However, we *should* anchor, instead of just producing an abs path.
I can imagine a situation where, for example, rust-analyzer processes
crates from different machines (or, for example, from in-memory git
branch), where the same absolute path in different crates might refer
to different files in the end!
4876: Syntactic highlighting of NAME_REF for injections r=matklad a=ltentrup
This commit adds a function that tries to determine the syntax highlighting class of NAME_REFs based on the usage.
It is used for highlighting injections (such as highlighting of doctests) as the semantic logic will most of the time result in unresolved references.
It also adds a color to unresolved references in HTML encoding.
Follow up of #4683.
Fixes#4809.
Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
This commit adds a function that tries to determine the syntax highlighting class of NAME_REFs based on the usage.
It is used for highlighting injections (such as highlighting of doctests) as the semantic logic will most of the time result in unresolved references.
It also adds a color to unresolved references in HTML encoding.
4860: Accept relative paths in rust-project.json r=matklad a=tweksteen
If a relative path is found as part of Crate.root_module or Root.path, interpret it as relative to the location of the rust-project.json file.
Fixes: #4816
Co-authored-by: Thiébaud Weksteen <tweek@google.com>
4882: _match.rs: improve comment formatting r=matklad a=jonas-schievink
This results in much nicer rustdoc output
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
It's a good idea to distinguish between absolute and relative paths at
the type level, to avoid accidental dependency on the cwd, which
really shouldn't matter for rust-analyzer service
4700: Add top level keywords completion r=matklad a=mcrakhman
This fixes the following issue: https://github.com/rust-analyzer/rust-analyzer/issues/4566.
Also added simple logic which filters the keywords which can be used with unsafe on the top level.
Co-authored-by: Mikhail Rakhmanov <rakhmanov.m@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
4857: Fix invalid shorthand initialization diagnostic for tuple structs r=jonas-schievink a=OptimalStrategy
Initializing tuple structs explicitly, like in the example below, produces a "Shorthand struct initialization" diagnostic that leads to a compilation error when applied:
```rust
struct S(usize);
fn main() {
let s = S { 0: 0 }; // OK, but triggers the diagnostic
// let s = S { 0 }; // Compilation error
}
```
This PR adds a check that the field name is not a literal.
Co-authored-by: OptimalStrategy <george@usan-podgornov.com>
Co-authored-by: OptimalStrategy <17456182+OptimalStrategy@users.noreply.github.com>
4833: Separating parsing of `for` in predicates and types r=matklad a=matthewjasper
We now correctly accept `for<'a> (&'a F): Fn(&'a str)` in a where clause and correctly reject `for<'a> &'a u32` as a type.
Co-authored-by: Matthew Jasper <mjjasper1@gmail.com>
4849: Make known paths use `core` instead of `std` r=matklad a=jonas-schievink
I'm not sure if this causes problems today, but it seems like it easily could, if rust-analyzer processes the libstd sources for the right `--target` and that target is a `#![no_std]`-only target.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
4819: Add an FST index to `ImportMap` and use it to speed up auto import r=matklad a=jonas-schievink
For the importing crate, we still use the symbol index, but I've modified it to only look at files that comprise that crate (instead of the whole workspace).
Oh, and since now the symbol query limit is respected correctly, it's possible that some results from the local crate now disappear if there are many matches.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/4763
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
4834: In field patterns, don't highlight local binding as a field r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
4822: Let checkOnSafe default to some of the options of cargo r=matklad a=clemenswasser
This will fix#4631
The implementation works (as far as I have tested) but is suboptimal because I am copying the "cargo.features".
Co-authored-by: Clemens Wasser <clemens.wasser@gmail.com>
4824: Correct "debug_assertion" to "debug_assertions" to match the cfg that the rust debug assert macros use. r=matklad a=woody77
This is for #4823.
Co-authored-by: Aaron Wood <aaronwood@google.com>
4576: Add implementation of extract struct from enum variant r=matklad a=mcrakhman
Hi guys! I implemented the extraction functionality including modifying multiple files. The only thing I didn't change the cursor position. I've done it with a previous API, but now snippets have been introduced and I need to figure out how to do it.
Please bear in mind that I am a newcomer in the rust-analyzer (and also Rust) world, so I tried to implement the feature to the best of my knowledge, but the API is very new to me, so I am very welcome to introducing changes etc.
Co-authored-by: Mikhail Rakhmanov <rakhmanov.m@gmail.com>
4784: Change management of test cfg to better support json projects r=Nashenas88 a=Nashenas88
This helps support json projects where they can decide whether to add the `test` cfg or not. One alternative is to add support for marking json project crates as a sysroot crate, and adding logic to remove the `test` cfg in those cases. In my opinion, that option gives less flexibility to json projects and leads to more functionality that needs to be maintained.
Fixes#4508
cc @woody77
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
Co-authored-by: Paul Daniel Faria <nashenas88@users.noreply.github.com>
4775: Add goto def for enum variant field r=matklad a=unexge
Closes#4764. I'm not familiar with ra codebase, there might be better ways to do that 😄
Co-authored-by: unexge <unexge@gmail.com>
4683: Implement syntax highlighting for doctests r=ltentrup a=ltentrup
The implementation is more complicated than the previous injection logic as the doctest comments consist of multiple ranges. The implementation extracts the doctests together with an offset-mapping, applies the syntax highlighting, and updates the text ranges.
<img width="478" alt="Bildschirmfoto 2020-06-01 um 15 45 25" src="https://user-images.githubusercontent.com/201808/83415249-1f0b5800-a41f-11ea-8fa6-c282434d6ff7.png">
Part of #4170.
Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
4781: Remove redundancy in syntax highlighting tests r=matklad a=ltentrup
Follow up from #4683. Improves syntax highlighting testing by introducing a function that contains the boilerplate comparison code. Keeps the `ra_fixture` argument in the first position, thus, the editor syntax highlighting injection still works.
Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
4770: Clean up handling of int/float literal types r=matklad a=flodiebold
'Unknown' int/float types actually never exist as such, they get replaced by type variables immediately. So the whole `Uncertain<IntTy>` thing was unnecessary and just led to a bunch of match branches that were never hit.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
'Unknown' int/float types actually never exist as such, they get replaced by
type variables immediately. So the whole `Uncertain<IntTy>` thing was
unnecessary and just led to a bunch of match branches that were never hit.
4689: Implement return position impl trait / opaque type support r=matklad a=flodiebold
This is working, but I'm not that happy with how the lowering works. We might need an additional representation between `TypeRef` and `Ty` where names are resolved and `impl Trait` bounds are separated out, but things like inference variables don't exist and `impl Trait` is always represented the same way.
Also note that this doesn't implement correct handling of RPIT *inside* the function (which involves turning the `impl Trait`s into variables and creating obligations for them). That intermediate representation might help there as well.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
4729: Hover actions r=matklad a=vsrs
This PR adds a `hoverActions` LSP extension and a `Go to Implementations` action as an example:
4748: Add an `ImportMap` and use it to resolve item paths in `find_path` r=matklad a=jonas-schievink
Removes the "go faster" queries I added in https://github.com/rust-analyzer/rust-analyzer/pull/4501 and https://github.com/rust-analyzer/rust-analyzer/pull/4506. I've checked this PR on the rustc code base and the assists are still fast.
This should fix https://github.com/rust-analyzer/rust-analyzer/issues/4515.
Note that this does introduce a change in behavior: We now always refer to items defined in external crates using paths through the external crate. Previously we could also use a local path (if for example the extern crate was reexported locally), as seen in the changed test. If that is undesired I can fix that, but the test didn't say why the previous behavior would be preferable.
Co-authored-by: vsrs <vit@conrlab.com>
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
This is working, but I'm not that happy with how the lowering works. We might
need an additional representation between `TypeRef` and `Ty` where names are
resolved and `impl Trait` bounds are separated out, but things like inference
variables don't exist and `impl Trait` is always represented the same
way.
Also note that this doesn't implement correct handling of RPIT *inside* the
function (which involves turning the `impl Trait`s into variables and creating
obligations for them). That intermediate representation might help there as
well.
