aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | | | | insta 0.16kjeremy2020-04-145-6/+6
| |/ / / / / /
* | | | | | | Merge #3971bors[bot]2020-04-155-4/+127
|\ \ \ \ \ \ \ | |/ / / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3971: add diagnostics subcommand to rust-analyzer CLI r=JoshMcguigan a=JoshMcguigan This PR adds a `diagnostics` subcommand to the rust-analyzer CLI. The intent is to detect all diagnostics on a workspace. It returns a non-zero status code if any error diagnostics are detected. Ideally I'd like to run this in CI against the rust analyzer project as a guard against false positives. ``` $ cargo run --release --bin rust-analyzer -- diagnostics . ``` Questions for reviewers: 1. Is this the proper way to get all diagnostics for a workspace? It seems there are at least a few ways this can be done, and I'm not sure if this is the most appropriate mechanism to do this. 2. It currently prints out the relative file path as it is collecting diagnostics, but it doesn't print the crate name. Since the file name is relative to the crate there can be repeated names, so it would be nice to print some identifier for the crate as well, but it wasn't clear to me how best to accomplish this. Co-authored-by: Josh Mcguigan <[email protected]>
| * | | | | | diagnostics cli, iterate over membersJosh Mcguigan2020-04-152-19/+27
| | | | | | |
| * | | | | | cli diagnostics walk filesJosh Mcguigan2020-04-143-50/+51
| | | | | | |
| * | | | | | add diagnostics subcommand to rust-analyzer CLIJosh Mcguigan2020-04-144-3/+117
| |/ / / / /
* | | | | | Merge #3961bors[bot]2020-04-131-3/+30
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3961: Fix double comma when merge imports on second line r=edwin0cheng a=IceSentry This fixes the bug when merging imports from the second line when it already has a comma it would previously insert a comma. There's probably a better way to check for a COMMA. This also ends up with a weird indentation, but rust-fmt can easily deal with it so I'm not sure how to resolve that. Closes #3832 Co-authored-by: IceSentry <[email protected]>
| * | | | | | Fix PRIceSentry2020-04-131-14/+8
| | | | | | |
| * | | | | | Generalize test and clean up importsIceSentry2020-04-131-8/+7
| | | | | | |
| * | | | | | Fix double comma when merge imports on second lineIceSentry2020-04-131-3/+37
| |/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the a bug when merging imports from the second line when it already has a comma it would previously insert a comma. There's probably a better way to check for a COMMA. This also ends up with a weird indentation, but rust-fmt can easily deal with it so I'm not sure how to resolve that. Closes #3832
* | | | | | Merge #3960bors[bot]2020-04-134-58/+141
|\ \ \ \ \ \ | |/ / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3960: ellipsis in tuple patterns r=JoshMcguigan a=JoshMcguigan This PR lowers ellipsis in tuple patterns. It fixes a bug in the way ellipsis were previously lowered (by replacing the ellipsis with a single `Pat::Wild` no matter how many items the `..` was taking the place of). It also uses this new information to properly handle `..` in tuple struct patterns when perform match statement exhaustiveness checks. While this PR provides the building blocks for match statement exhaustiveness checks for tuples, there are some additional challenges there, so that is still unimplemented (unlike tuple structs). Co-authored-by: Josh Mcguigan <[email protected]>
| * | | | | handle tuple patterns with ellipsisJosh Mcguigan2020-04-134-58/+141
| | | | | |
* | | | | | Merge #3957bors[bot]2020-04-121-2/+2
|\ \ \ \ \ \ | |/ / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3957: Remove more unnecessary braces r=kjeremy a=lnicola See #3866. Co-authored-by: Laurențiu Nicola <[email protected]>
| * | | | | Remove more unnecessary bracesLaurențiu Nicola2020-04-121-2/+2
|/ / / / /
* | | | | Merge #3938bors[bot]2020-04-122-12/+253
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3938: fix missing match arm false positive r=flodiebold a=JoshMcguigan This fixes #3932 by skipping the missing match arm diagnostic in the case any of the match arms don't type check properly against the match expression. I think this is the appropriate behavior for this diagnostic, since `is_useful` relies on all match arms being well formed, and the case of a malformed match arm should probably be handled by a different diagnostic. Co-authored-by: Josh Mcguigan <[email protected]>
| * | | | | missing match arm add test cases to demonstrate enum tuple struct with ↵Josh Mcguigan2020-04-121-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | ellipsis behavior
| * | | | | missing match arms add test cases to demonstrate behavior of tuple with patternJosh Mcguigan2020-04-121-0/+75
| | | | | |
| * | | | | missing match arm add test for partially diverging typeJosh Mcguigan2020-04-111-0/+21
| | | | | |
| * | | | | missing match arms add tests for match expression divergingJosh Mcguigan2020-04-111-0/+77
| | | | | |
| * | | | | fix match arm false positiveJosh Mcguigan2020-04-112-12/+16
| | | | | |
* | | | | | Merge #3955bors[bot]2020-04-1119-97/+149
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3955: Align grammar for record patterns and literals r=matklad a=matklad The grammar now looks like this [name_ref :] pat bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | | Align grammar for record patterns and literalsAleksey Kladov2020-04-1118-90/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The grammar now looks like this [name_ref :] pat
| * | | | | | Remove dead codeAleksey Kladov2020-04-111-7/+4
| | |_|_|_|/ | |/| | | |
* | | | | | Merge #3953bors[bot]2020-04-111-6/+15
|\ \ \ \ \ \ | |/ / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3953: Remove #[should_panic] from call_info tests r=matklad a=kjeremy Better fix than #3952 Co-authored-by: Jeremy Kolb <[email protected]>
| * | | | | Remove #[should_panic] from call_info testsJeremy Kolb2020-04-111-6/+15
|/ / / / /
* | | | | Merge #3925bors[bot]2020-04-115-1/+262
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3925: Implement assist "Reorder field names" r=matklad a=geoffreycopin This PR implements the "Reorder record fields" assist as discussed in issue #3821 . Adding a `RecordFieldPat` variant to the `Pat` enum seemed like the easiest way to handle the `RecordPat` children as a single sequence of elements, maybe there is a better way ? Co-authored-by: Geoffrey Copin <[email protected]>
| * | | | | Generate docGeoffrey Copin2020-04-112-0/+30
| | | | | |
| * | | | | Fix doc testsGeoffrey Copin2020-04-111-2/+1
| | | | | |
| * | | | | Add documentation commentGeoffrey Copin2020-04-111-0/+16
| | | | | |
| * | | | | Avoid adding a RecordFieldPat variant to the Pat enumGeoffrey Copin2020-04-114-49/+48
| | | | | |
| * | | | | Remove Option unwrapingGeoffrey Copin2020-04-111-3/+3
| | | | | |
| * | | | | Implement assist "Reorder field names"Geoffrey Copin2020-04-095-2/+219
| | | | | |
* | | | | | Merge #3951bors[bot]2020-04-1117-121/+180
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3951: Simplify records grammar r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | | Remove dead codeAleksey Kladov2020-04-118-55/+40
| | | | | | |
| * | | | | | Make records grammar more orthogonalAleksey Kladov2020-04-1113-68/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We used name [: expr] grammar before, now it is [name :] expr which makes things simpler
* | | | | | | Merge #3944bors[bot]2020-04-114-14/+65
|\ \ \ \ \ \ \ | |/ / / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3944: Look up trait impls by self type r=matklad a=flodiebold This speeds up inference in analysis-stats by ~30% (even more with the recursive solver). There's a slight difference in inferred types, which I think comes from pre-existing wrong handling of error types in impls, so I think it's fine. Co-authored-by: Florian Diebold <[email protected]>
| * | | | | | Look up impls by self typeFlorian Diebold2020-04-114-14/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This speeds up inference in analysis-stats by ~30% (even more with the recursive solver).
* | | | | | | Merge #3949bors[bot]2020-04-117-53/+102
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3949: Cleanup cfg handling in items r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | | | Make incremental nameres test harderAleksey Kladov2020-04-111-0/+6
| | | | | | | |
| * | | | | | | Avoid cyclic queries in name resolution when processing enumsAleksey Kladov2020-04-113-15/+48
| | | | | | | |
| * | | | | | | Align namingAleksey Kladov2020-04-114-6/+5
| | | | | | | |
| * | | | | | | Remove code duplicationAleksey Kladov2020-04-112-5/+2
| | | | | | | |
| * | | | | | | Use Expander for cfg handling in structsAleksey Kladov2020-04-111-10/+10
| | | | | | | |
| * | | | | | | Use Expander for cfg handling in implsAleksey Kladov2020-04-111-13/+14
| | | | | | | |
| * | | | | | | Pull Expander upAleksey Kladov2020-04-113-11/+24
| | | | | | | |
| * | | | | | | SimplifyAleksey Kladov2020-04-112-8/+8
|/ / / / / / /
* | | | | | | Merge pull request #3935 from cjhopman/todoAleksey Kladov2020-04-115-20/+32
|\ \ \ \ \ \ \ | |_|_|_|_|/ / |/| | | | | | Change missing impl assist to use todo!() instead of unimplemented()
| * | | | | | Change missing impl assist to use todo!() instead of unimplemented()Chris Hopman2020-04-105-20/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | todo!() "Indicates unfinished code" (https://doc.rust-lang.org/std/macro.todo.html) Rust documentation provides further clarification: > The difference between unimplemented! and todo! is that while todo! > conveys an intent of implementing the functionality later and the > message is "not yet implemented", unimplemented! makes no such claims. todo!() seems more appropriate for assists that insert missing impls.
* | | | | | | Merge #3942bors[bot]2020-04-111-9/+30
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3942: vscode: fix typing bug in config r=matklad a=Veetaha I noticed that the type of nullable properties in config is actually non-nullable ![Screenshot from 2020-04-11 15-29-45](https://user-images.githubusercontent.com/36276403/79043702-6a686d80-7c09-11ea-9ae8-f1a777c7d0f2.png) Co-authored-by: veetaha <[email protected]>
| * | | | | | | vscode: fix typing bug in configveetaha2020-04-111-9/+30
| | |_|_|_|/ / | |/| | | | |
* | | | | | | Merge #3943bors[bot]2020-04-111-5/+5
|\ \ \ \ \ \ \ | |_|_|/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3943: vscode: fix indent r=matklad a=Veetaha Co-authored-by: veetaha <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-24 11:28:03 +0000