aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | | Better Sublime documentationElinvynia2020-04-081-24/+1
|/ / / / /
* | | | | Merge #3899bors[bot]2020-04-084-18/+8
|\ \ \ \ \ | |_|_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3899: Enable the SemanticTokensFeature by default r=matklad a=kjeremy This is covered under vscode's "editor.semanticHighlighting.enabled" setting plus the user has to have a theme that has opted into highlighting. Bumps required vscode stable to 1.44 Closes #3773 Co-authored-by: kjeremy <[email protected]>
| * | | | Enable the SemanticTokensFeature by defaultkjeremy2020-04-084-18/+8
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | This is covered under vscode's "editor.semanticHighlighting.enabled" setting plus the user has to have a theme that has opted into highlighting. Bumps required vscode stable to 1.44
* | | | Merge #3884bors[bot]2020-04-081-15/+59
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3884: Match check fix missing pattern panic r=flodiebold a=JoshMcguigan As reported by @cynecx, match arm exhaustiveness checking could panic when tuple enums were missing their pattern. This was reported in the comments of #3706. This fixes the panic, and adds a similar test to ensure tuples don't have this problem. It turns out malformed tuple patterns are caught in the "type check" outside the `is_useful` function, while malformed enum tuple patterns are not. This makes sense to me in hindsight, since the type checker can tell that an enum is the right type even if it is missing its internal pattern, but a tuple (non-enum) just becomes a different type if it is "missing" its pattern. This discrepency is why we report a diagnostic in the tuple case (because all arms are filtered out, so there are missing arms), but not in the enum tuple case (because we return an `Err(MalformedMatchArm)` from `is_useful`). I don't think this is that big of a deal, because in both cases this is malformed code and there should eventually be a `MalformedMatchArm` diagnostic or similar. But perhaps we should change things so that if any arm fails the type check we skip the entire diagnostic? That would at least make these two cases behave in the same way. @flodiebold Co-authored-by: Josh Mcguigan <[email protected]>
| * | | match checking add additional test for match checking tuple with missing patternJosh Mcguigan2020-04-081-0/+14
| | | |
| * | | fix panic in match checking when tuple enum missing patternJosh Mcguigan2020-04-081-15/+45
|/ / /
* | | Merge #3895bors[bot]2020-04-081-1/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3895: Fix warnings emitted when compiling as part of rustc r=matklad a=matklad bors r+ 🤖 Co-authored-by: Luca Barbieri <[email protected]>
| * | | Fix warnings emitted when compiling as part of rustcLuca Barbieri2020-04-081-1/+1
|/ / /
* | | Merge #3826bors[bot]2020-04-085-51/+148
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3826: Flatten nested highlight ranges during DFS traversal r=matklad a=ltentrup Implements the flattening of nested highlights from #3447. There is a caveat: I needed to add `Clone` to `HighlightedRange` to split highlight ranges ~and the nesting does not appear in the syntax highlighting test (it does appear in the accidental-quadratic test but there it is not checked against a ground-truth)~. I have added a test case for the example mentioned in #3447. Co-authored-by: Leander Tentrup <[email protected]>
| * | | Simplify HTML highlighter and add test case for highlight_injection logicLeander Tentrup2020-04-065-59/+97
| | | |
| * | | Flatten nested highlight ranges during DFS traversalLeander Tentrup2020-04-032-6/+65
| | | |
* | | | Merge #3892bors[bot]2020-04-082-1/+18
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3892: Add L_DOLLAR for TYPE_RECOVERY_SET r=matklad a=edwin0cheng This PR is a hot fix for issue #3861 that just prevent it make the parser being stuck. The actual problem described in https://github.com/rust-analyzer/rust-analyzer/pull/3873#issuecomment-610208693 is a very deep rabbit hole I don't want to dig right now :( Co-authored-by: Edwin Cheng <[email protected]>
| * | | | Add L_DOLLAR for TYPE_RECOVERY_SETEdwin Cheng2020-04-082-1/+18
| | | | |
* | | | | fmtAleksey Kladov2020-04-083-6/+7
| | | | |
* | | | | Don't strip nightly releasesAleksey Kladov2020-04-085-24/+21
|/ / / /
* | | | Merge #3879bors[bot]2020-04-072-25/+25
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3879: Update some packages r=matklad a=kjeremy Co-authored-by: kjeremy <[email protected]>
| * | | | Update some packageskjeremy2020-04-072-25/+25
| | | | |
* | | | | Merge #3882bors[bot]2020-04-075-168/+198
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3882: Move computation of missing fields into hir r=matklad a=matklad cc @SomeoneToIgnore, this is that refactoring that moves computation of missing fields to hir. it actually removes meaningful duplication between diagnostics code and the completion code. Nontheless, it's a net addition of code :( Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | Move computation of missing fields into hirAleksey Kladov2020-04-075-168/+198
| | | | | |
* | | | | | Merge #3881bors[bot]2020-04-071-2/+35
|\| | | | | | |_|_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3881: Add functional update test r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Add functional update testAleksey Kladov2020-04-071-0/+33
| | | | |
| * | | | Fix names of test modulesAleksey Kladov2020-04-071-2/+2
|/ / / /
* | | | Merge #3878bors[bot]2020-04-074-7/+52
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3878: A more precise panic macro r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | A more precise panic macroAleksey Kladov2020-04-071-1/+1
| | | |
| * | | Don't insert !() if there's already someAleksey Kladov2020-04-073-3/+45
| | | |
| * | | Reorder importsAleksey Kladov2020-04-071-3/+6
| | | |
* | | | Merge #3706bors[bot]2020-04-0712-11/+1552
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3706: missing match arms diagnostic r=flodiebold a=JoshMcguigan Following up on https://github.com/rust-analyzer/rust-analyzer/pull/3689#issuecomment-602718222, this PR creates a missing match arms diagnostic. At the moment this is a very early draft, but I wanted to open it just to get some initial feedback. Initial questions: * Have I roughly created the correct boilerplate? * Inside the new `validate_match` function: * Am I correct in thinking I want to do validation by comparing the match arms against `match_expr`? And when analyzing `match_expr` I should be looking at it as a `hir_def::expr::Expr`? * I mostly copied the chained if-let statements from the struct validation. Shouldn't there be a non-failable way to get an AstPtr from the hir data structures? Thanks for all the guidance. Co-authored-by: Josh Mcguigan <[email protected]>
| * | | add fixme to use type checker rather than manually comparing typesJosh Mcguigan2020-04-071-0/+7
| | | |
| * | | PR feedback implementationJosh Mcguigan2020-04-071-94/+331
| | | |
| * | | missing match arms diagnostic change source to match expressionJosh Mcguigan2020-04-073-3/+7
| | | |
| * | | handle match auto-derefJosh Mcguigan2020-04-072-1/+45
| | | |
| * | | improving documentationJosh Mcguigan2020-04-071-16/+64
| | | |
| * | | handle non matching enum pattern typesJosh Mcguigan2020-04-072-41/+57
| | | |
| * | | remove panicsJosh Mcguigan2020-04-072-66/+214
| | | |
| * | | missing match arms diagnosticJosh Mcguigan2020-04-0712-11/+1048
|/ / /
* | | Merge #3876bors[bot]2020-04-073-6/+6
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3876: Better naming for scope completion r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | Better naming for scope completionAleksey Kladov2020-04-073-4/+4
| | | |
| * | | Better naming for path completionAleksey Kladov2020-04-073-4/+4
|/ / /
* | | Merge pull request #3863 from Veetaha/feature/migrate-to-rastAleksey Kladov2020-04-07278-25/+23
|\ \ \ | | | | | | | | Migrate tests .txt -> .rast
| * | | Migrate tests .txt -> .rastveetaha2020-04-06278-25/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The sytax tree output files now use .rast extension (rust-analyzer syntax tree or rust abstract syntax tree (whatever)). This format has a editors/code/ra_syntax_tree.tmGrammar.json declaration that supplies nice syntax highlighting for .rast files.
* | | | Merge #3875bors[bot]2020-04-071-2/+2
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3875: When making a release, just promote the latest nightly r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | When making a release, just promote the latest nightlyAleksey Kladov2020-04-071-2/+2
|/ / / /
* | | | Fix yamlAleksey Kladov2020-04-071-1/+1
| | | |
* | | | Fix yamlAleksey Kladov2020-04-071-1/+1
| | | |
* | | | Merge pull request #3866 from lnicola/fewer-bracesAleksey Kladov2020-04-0712-73/+73
|\ \ \ \ | | | | | | | | | | Fix unnecessary braces warnings
| * | | | Fix unnecessary braces warningsLaurențiu Nicola2020-04-0612-73/+73
| | | | |
* | | | | Merge #3874bors[bot]2020-04-071-6/+14
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3874: Better config scheme & defaults r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | Better config scheme & defaultsAleksey Kladov2020-04-071-6/+14
| | | | | |
* | | | | | Run analysis-stats nightlyAleksey Kladov2020-04-071-0/+4
| | | | | |
* | | | | | Merge #3872bors[bot]2020-04-071-15/+25
|\ \ \ \ \ \ | |/ / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3872: fix cargo check config with custom command r=matklad a=JoshMcguigan fixes #3871 Previously if `get::<Vec<String>>(value, "/checkOnSave/overrideCommand")` returned `Some` we'd never execute `set(value, "/checkOnSave/command", command)`, even if the `overrideCommand` was empty. I am not sure of the best way to prove this, but I believe the LSP clients send this config with a default value if it is not set by the user, which means `get::<Vec<String>>(value, "/checkOnSave/overrideCommand")` would return `Some(vec![])` and thus we'd never set the command to the user specified value (in the case of #3871, "clippy"). I have tested this fix manually by installing this modified version of rust-analyzer and verifying I can see clippy lints in my editor (`coc.nvim`) with `rust-analyzer.checkOnSave.command": "clippy"`. As best I can tell this would have affected rustfmt extra args too, so this PR also applies the same fix there. Co-authored-by: Josh Mcguigan <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-29 17:24:19 +0000