aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Reduce bors timeoutAleksey Kladov2020-10-141-0/+1
|
* Merge #6217bors[bot]2020-10-143-17/+20
|\ | | | | | | | | | | | | | | 6217: Bump pulldown-cmark r=matklad a=lnicola Co-authored-by: Laurențiu Nicola <[email protected]>
| * Bump pulldown-cmarkLaurențiu Nicola2020-10-133-17/+20
| |
* | Merge #6222bors[bot]2020-10-143-2/+53
|\ \ | |/ |/| | | | | | | | | | | | | | | 6222: Fix stackoverflow in insert_use::recursive_merge r=matklad a=Veykril Fixes #6221. #6108 shouldn't be related to this as autocompletion doesn't depend on this code. Co-authored-by: Lukas Wirth <[email protected]>
| * Fix stackoverflow in insert_use::recursive_mergeLukas Wirth2020-10-143-2/+53
|/
* Merge #6216bors[bot]2020-10-136-31/+58
|\ | | | | | | | | | | | | | | 6216: Bump deps r=matklad a=lnicola Co-authored-by: Laurențiu Nicola <[email protected]>
| * Bump regexLaurențiu Nicola2020-10-131-4/+4
| |
| * Bump rustc_lexerLaurențiu Nicola2020-10-132-3/+3
| |
| * Bump crossbeam-channel and lsp-server in rust-analyzerLaurențiu Nicola2020-10-132-6/+6
| |
| * Bump crossbeam-channel in cratesLaurențiu Nicola2020-10-134-15/+43
| |
| * Bump some depsLaurențiu Nicola2020-10-131-8/+8
| |
| * Remove Cargo.lock commentLaurențiu Nicola2020-10-131-1/+0
| |
* | Merge #6209bors[bot]2020-10-132-4/+33
|\ \ | | | | | | | | | | | | | | | | | | | | | 6209: Fix MergeBehaviour::Full/Last not working when merging nested long paths r=matklad a=Veykril Prior to this inserting `std::foo::bar::Baz` with a nested import containing a multi segment path like `use std::{foo::bar::Qux};` present would result in `use std::{foo::bar::Baz, foo::bar::Qux};` with Full/Last Mergebehaviour. Co-authored-by: Lukas Wirth <[email protected]>
| * | Fix MergeBehaviour::Full not working when merging nested long pathsLukas Wirth2020-10-132-4/+33
| |/
* | Merge #6213bors[bot]2020-10-131-2/+2
|\ \ | |/ |/| | | | | | | | | | | 6213: Fix resolveCodeAction request r=SomeoneToIgnore a=lnicola Fixes #6204 Co-authored-by: Laurențiu Nicola <[email protected]>
| * Fix resolveCodeAction requestLaurențiu Nicola2020-10-131-2/+2
|/
* Merge #6208bors[bot]2020-10-123-1/+10
|\ | | | | | | | | | | | | | | | | 6208: macOS: install GNU tar r=jonas-schievink a=jonas-schievink CI runs on macOS have started to fail due to https://github.com/actions/cache/issues/403. Use GNU tar instead of BSD tar to work around that. Co-authored-by: Jonas Schievink <[email protected]> Co-authored-by: Jonas Schievink <[email protected]>
| * Remove disabled builderJonas Schievink2020-10-121-1/+0
| |
| * Add comment and link to upstream issueJonas Schievink2020-10-121-0/+2
| |
| * Reenable bors gate for macOSJonas Schievink2020-10-121-1/+2
| |
| * macOS: install GNU tarJonas Schievink2020-10-122-0/+7
|/
*-. Merge #6130 #6135bors[bot]2020-10-1215-84/+1407
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6130: Items case quick fix (snake_case / UPPER_SNAKE_CASE / CamelCase) r=matklad a=popzxc Resolves #4598. After a third try, it finally works. Boy, it appeared tougher than it seemed. Initially I thought like "Ha, `rustc` already tells us where idents are named incorrectly. It shouldn't be that hard, should it?". Well, the problems with the information provided by `rustc` appeared shortly: - `rustc` warnings are `flycheck` warnings, which are slightly aside from our diagnostics with fixes. When we map flycheck diagnostic to LSP, we can convert it into a fix, but only if it's marked as `Applicability::MachineApplicable`. Name case fix is marked `Applicability::MaybeIncorrect`, and for a reason: it only suggest to rename symbol under cursor, without tracking any references. - Warning spawned by `rustc` are identified by string labels rather than enum. It means that if one day the diagnostic will be renamed in `rustc`, `rust-analyzer` code will still compile, but won't find the required diagnostic by name anymore. If by chance this will happen when some unlucky guy will decide to create their first pull request, they'll be confused by suddenly failing tests (likely) not related to their changes. - Even if we'll try to build fixes atop of `rustc` warnings, we'll have to do it in the `rust_analyzer::diagnostics::to_proto` module, which is far less convenient for that matter than `ide` crate. That's why I decided that it's worth a separate `rust-analyzer` diagnostic, which will implement `DiagnosticWithFix` trait. After that, I discovered that currently `hir_ty::diagnostics` only check `DefWithBody` types, like function bodies. I had to add support for diagnostics which look at any `ModuleDef`. And of course, since I'd added a lot of new functionality, it required extensive testing. That explains why the diff is so big for a (looking) relatively small feature. I hope that this PR doesn't only add a small feature, but also creates a base for building another features. ## Example: ![case_quick_fix](https://user-images.githubusercontent.com/12111581/95008475-e07ee780-0622-11eb-9978-62a9ea0e7782.gif) P.S. My eyes were bleeding when I had to write the code for the example... 6135: when generating new function, focus on return type instead of body r=matklad a=bnjjj I made a little change when we use the assist to generate a new function, instead of focusing on the function body, it will focus on return type Co-authored-by: Igor Aleksanov <[email protected]> Co-authored-by: Benjamin Coenen <[email protected]>
| | * when generating new function, focus on return type instead of bodyBenjamin Coenen2020-10-083-68/+80
| | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
| * | Use TextRange::contains_inclusive in fixes checkIgor Aleksanov2020-10-122-5/+4
| | |
| * | Keep SyntaxNodePtr::range privateIgor Aleksanov2020-10-124-9/+17
| | |
| * | Replace 'if let' with 'match' in decl_check.rsIgor Aleksanov2020-10-121-30/+33
| | |
| * | Add to_upper_snake_case function to stdxIgor Aleksanov2020-10-123-6/+13
| | |
| * | Fix compilation errorIgor Aleksanov2020-10-121-2/+1
| | |
| * | Apply suggestions from code reviewIgor Aleksanov2020-10-122-3/+3
| | | | | | | | | Co-authored-by: Lukas Wirth <[email protected]>
| * | Fix code style issuesIgor Aleksanov2020-10-123-4/+7
| | |
| * | Apply case check diagnostic to impl itemsIgor Aleksanov2020-10-122-1/+26
| | |
| * | Fix issues with match arm bindingsIgor Aleksanov2020-10-121-7/+12
| | |
| * | Code style adjustmentsIgor Aleksanov2020-10-123-8/+88
| | |
| * | Remove previously added parameter names from the function dataIgor Aleksanov2020-10-123-18/+0
| | |
| * | Make incorrect case diagnostic work inside of functionsIgor Aleksanov2020-10-124-33/+280
| | |
| * | Refactor string helpers for decl_check moduleIgor Aleksanov2020-10-121-32/+97
| | |
| * | Add diagnostics for enum names and variantsIgor Aleksanov2020-10-123-2/+173
| | |
| * | Add fix for incorrect case diagnosticIgor Aleksanov2020-10-128-30/+112
| | |
| * | Improve string helpers functionsIgor Aleksanov2020-10-122-2/+13
| | |
| * | Check structure fields to be snake_caseIgor Aleksanov2020-10-121-46/+65
| | |
| * | Add check for structure names to be CamelCaseIgor Aleksanov2020-10-122-1/+139
| | |
| * | Extract helper functions into a separate moduleIgor Aleksanov2020-10-122-29/+112
| | |
| * | Add checks for function parametersIgor Aleksanov2020-10-122-7/+94
| | |
| * | Create basic support for names case checks and implement function name case ↵Igor Aleksanov2020-10-126-3/+300
| | | | | | | | | | | | check
* | | Merge #6205bors[bot]2020-10-121-2/+2
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6205: Fix iterator hint shortening heuristic r=SomeoneToIgnore a=Veykril Turns out I made a mistake with the heuristic check which is always true, so all iterators exposed from `core` were shortened, including things like ranges. 😅 Co-authored-by: Lukas Wirth <[email protected]>
| * | | Fix iterator hint shortening heuristicLukas Wirth2020-10-121-2/+2
| | | |
* | | | Merge #6137bors[bot]2020-10-121-684/+1041
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6137: add a new TextMate grammar r=matklad a=dustypomerleau Thanks to everyone working hard on Rust Analyzer - my impression is that it's quickly becoming the community default. I think it would be helpful to have a more robust TextMate grammar to fall back on, for those who wish to disable semantic highlighting for any reason. It should allow theming of punctuation, and provide scopes for all tokens on the page. This can be done at zero cost to those who enable semantic highlighting, as the TextMate scopes will be invisible to those users. I can see a couple ways of accomplishing this: 1. Ship a new grammar by merging this PR. 1. Ship no TextMate grammar at all (like the [Rust](https://marketplace.visualstudio.com/items?itemName=rust-lang.rust) extension), and allow users to install a separate extension that provides the grammar of their choice (I have released this one as [Rust Syntax](https://marketplace.visualstudio.com/items?itemName=dustypomerleau.rust-syntax)). If no grammar were installed, they would simply fall back to the default grammar provided by their editor. In the case of VS Code, the default grammar already matches what is currently being shipped, so users who choose not to override it would see no difference. I have tried to choose sensible default scopes, in the hopes that a wider variety of themes would work out of the box with Rust, even if those themes do not yet supply scopes for semantic highlighting. There is definitely some interest in using this grammar with Rust Analyzer, as this was the very first issue after the syntax extension was shipped: https://github.com/dustypomerleau/rust-syntax/issues/1. I considered simply using an alternative grammar alongside Rust Analyzer, but this doesn't seem possible. When RA starts, any existing grammar/extension is overridden, and I haven't been able to find a workaround. Co-authored-by: Dusty Pomerleau <[email protected]>
| * | | | add new TextMate grammarDusty Pomerleau2020-10-111-684/+1041
| | | | |
* | | | | Merge #6153bors[bot]2020-10-125-13/+119
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6153: Improve prime_caches and display its progress r=matklad a=jonas-schievink It now computes the `CrateDefMap` of all crates, which is generally a reasonable approximation for "IDE features ready". There is still some delay after this finishes, I suspect mostly due to impl collection, which takes a while, but this should be an improvement already. For more accurate progress reports, this topologically sorts all crates before starting this operation. ~~Because that is also the ordering in which parallelization makes sense (which was previously attempted in https://github.com/rust-analyzer/rust-analyzer/pull/3529), I decided to throw that into the mix as well. It still doesn't provide *that* much of a performance boost, but it does scale beyond the current single-core architecture, and adding it was very easy.~~ ~~Unfortunately, as written, this will not tell the user which crate is actually causing slowdowns, since the displayed crate is the last one that was *started*, not the one we are currently *blocked* on, but that seems fairly difficult to implement unless I'm missing something.~~ (I have removed rayon for now since it does not work correctly with cancellation.) Co-authored-by: Jonas Schievink <[email protected]>
| * | | | Improve prime_caches and display its progressJonas Schievink2020-10-125-13/+119
| | |/ / | |/| |
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-30 06:16:35 +0000