aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge #4951bors[bot]2020-06-192-6/+31
|\ | | | | | | | | | | | | | | 4951: Don't panic on crates depending on themselves r=matklad a=flodiebold Fixes #3883. Co-authored-by: Florian Diebold <[email protected]>
| * Don't panic on crates depending on themselvesFlorian Diebold2020-06-192-6/+31
| | | | | | | | Fixes #3883.
* | Merge #4955bors[bot]2020-06-191-3/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | 4955: Update workaround comment r=matklad a=Veetaha Co-authored-by: Veetaha <[email protected]>
| * | Update workaround commentVeetaha2020-06-191-3/+2
| |/
* | Merge #4950bors[bot]2020-06-193-17/+47
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4950: Use correct substs for super trait assoc types r=matklad a=flodiebold 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. Co-authored-by: Florian Diebold <[email protected]>
| * | Use correct substs for super trait assoc typesFlorian Diebold2020-06-193-17/+47
|/ / | | | | | | | | | | | | | | 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.
* | Merge #4957bors[bot]2020-06-192-1/+33
|\ \ | |/ |/| | | | | | | | | | | | | | | | | 4957: Fix substs in resolve_value_path for ImplSelf r=flodiebold a=Speedy37 Fixes #4953. This is the first fix I do in hir_ty, I hope I got it right :) Co-authored-by: Vincent Rouillé <[email protected]>
| * Fix substs in resolve_value_path for ImplSelfVincent Rouillé2020-06-192-1/+33
|/ | | | Fixes #4953.
* Merge #4851bors[bot]2020-06-195-5/+134
|\ | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * Add quickfix to add a struct fieldTimo Freiberg2020-06-125-5/+134
| |
* | Merge #4937bors[bot]2020-06-191-1/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | Fix fmtoxalica2020-06-181-1/+2
| | |
| * | Allow overriding rust-analyzer display revisionoxalica2020-06-181-1/+3
| | |
* | | Merge #4839bors[bot]2020-06-1911-38/+1360
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4839: `Go to Type Definition` hover action. r=matklad a=vsrs ![hover_actions_goto](https://user-images.githubusercontent.com/62505555/83335671-0122e380-a2b7-11ea-9922-fbdcfb11a7f3.gif) This implementation supports things like `dyn Trait<SomeType>`, `-> impl Trait`, etc. Co-authored-by: vsrs <[email protected]>
| * | | Apply suggestions from code reviewvsrs2020-06-183-65/+328
| | | |
| * | | Add Type::walk methodvsrs2020-06-183-75/+132
| | | |
| * | | Remove AdtOrTraitvsrs2020-06-184-50/+39
| | | |
| * | | Add `rust-analyzer.gotoLocation` commandvsrs2020-06-186-8/+25
| | | |
| * | | Add associated type test.vsrs2020-06-183-2/+65
| | | |
| * | | Fix type "items" order.vsrs2020-06-182-24/+36
| | | |
| * | | Add `Go to Type Definition` hover action.vsrs2020-06-188-35/+956
| | | |
| * | | Fix rust-analyzer.debug.openDebugPane optionvsrs2020-06-182-2/+2
| | | |
| * | | Fix empty hover action group for a runnable.vsrs2020-06-181-1/+1
| | | |
* | | | Merge #4948bors[bot]2020-06-194-11/+30
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4948: Speedup VFS::partition r=matklad a=matklad 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. bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Speedup VFS::partitionAleksey Kladov2020-06-194-11/+30
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | Merge #4930bors[bot]2020-06-181-28/+49
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | | Avoid all unchecked indexing in match checkingJonas Schievink2020-06-171-28/+49
| | | | |
* | | | | Merge #4941bors[bot]2020-06-182-8/+4
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4941: Simplify r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | SimplifyAleksey Kladov2020-06-182-8/+4
| | |_|/ / | |/| | |
* | | | | Merge #4903bors[bot]2020-06-185-41/+56
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | | Remove logic to mark all doctest code asPaul Daniel Faria2020-06-182-14/+13
| | | | |
| * | | | Ensure all existing doctest code highlights have documentation modifierPaul Daniel Faria2020-06-173-21/+22
| | | | |
| * | | | Add highlighting support for doc commentsPaul Daniel Faria2020-06-175-41/+56
| | | | |
* | | | | Merge #4935bors[bot]2020-06-182-10/+4
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4935: Simplify r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | SimplifyAleksey Kladov2020-06-182-10/+4
| | |_|/ / | |/| | |
* | | | | Merge #4821bors[bot]2020-06-182-9/+32
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4821: display Doctest code lens before comment r=matklad a=bnjjj close #4785 Co-authored-by: Benjamin Coenen <[email protected]>
| * | | | display Doctest code lens before comment #4785Benjamin Coenen2020-06-182-9/+3
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
| * | | | display Doctest code lens before comment #4785Benjamin Coenen2020-06-141-2/+2
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
| * | | | display Doctest code lens before comment #4785Benjamin Coenen2020-06-092-3/+32
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
* | | | | Merge #4872bors[bot]2020-06-181-46/+43
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4872: Reduce the usage of bare subscript operator r=matklad a=Veetaha Co-authored-by: Veetaha <[email protected]>
| * | | | | Reduce the usage of bare subscript operatorVeetaha2020-06-141-46/+43
| | | | | |
* | | | | | Merge #4934bors[bot]2020-06-186-212/+69
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | | | | Remove special casing for library symbolsAleksey Kladov2020-06-186-212/+69
| | |_|_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | | | Merge #4932bors[bot]2020-06-181-10/+6
|\ \ \ \ \ \ | |/ / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4932: Simplify r=matklad a=Veetaha Co-authored-by: Veetaha <[email protected]>
| * | | | | SimplifyVeetaha2020-06-181-10/+6
|/ / / / /
* | | | | Merge #4927bors[bot]2020-06-172-24/+30
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | | | Better encapsulate reverse-mapping of files to cargo targetsAleksey Kladov2020-06-172-24/+30
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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...
* | | | | Merge #4925bors[bot]2020-06-1712-5/+38
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4925: Syntax highlighting for escape sequences in strings r=matklad a=ltentrup I have added a new semantic token type `ESCAPE_SEQUENCE` as the LSP specification does not seem to have an appropriate token type. This may actually be a regression for some users, as the TextMate Rust grammar has a scope `constant.character.escape.rust` which highlights escape sequences (which caused problems with semantic highlighting, see #4138). Fixes #2604. Co-authored-by: Leander Tentrup <[email protected]>
| * | | | Syntax highlighting for escape sequences in stringsLeander Tentrup2020-06-1712-5/+38
|/ / / /
| | | |
| \ \ \
| \ \ \
| \ \ \
*---. \ \ \ Merge #4913 #4915 #4916bors[bot]2020-06-1710-34/+426
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. ![image](https://user-images.githubusercontent.com/13839236/84830640-0bb8d900-b02a-11ea-9e2f-0561b0e8f1ef.png) ![image](https://user-images.githubusercontent.com/13839236/84826931-ffca1880-b023-11ea-8080-5e5b91a6ac0d.png) 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. ![image](https://user-images.githubusercontent.com/13839236/84827165-55062a00-b024-11ea-8bd6-bdbf1217c4c5.png) ### 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. ![image](https://user-images.githubusercontent.com/13839236/84829609-50437500-b028-11ea-80a8-1bbd05680ba7.png) ### 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 <[email protected]> Co-authored-by: Leander Tentrup <[email protected]> Co-authored-by: Gabriel Valfridsson <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-05 09:21:29 +0000