aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* | | Merge #4233bors[bot]2020-04-309-63/+30
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4233: Remove dead TryBlock expressio r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | Kill more zombiesAleksey Kladov2020-04-302-9/+0
| | | |
| * | | Introduce BlockModifierAleksey Kladov2020-04-302-2/+19
| | | |
| * | | Remove dead code, which elaborately pretends to be aliveAleksey Kladov2020-04-306-52/+11
| | | |
* | | | Merge #4228bors[bot]2020-04-301-3/+3
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4228: Fix typo in language server binary docs r=matklad a=ayazhafiz Co-authored-by: hafiz <[email protected]>
| * | | | Update readme.adochafiz2020-04-301-2/+2
| | | | |
| * | | | Fix typo in language server binary docshafiz2020-04-301-1/+1
| | | | |
* | | | | Merge #4232bors[bot]2020-04-301-1/+1
|\ \ \ \ \ | |_|_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4232: Update Roslyn link in syntax.md r=matklad a=osa1 Eric Lippert has a new blog that he keeps updating, update the link to that Co-authored-by: Ömer Sinan AÄŸacan <[email protected]>
| * | | | Update Roslyn link in syntax.mdÖmer Sinan Ağacan2020-04-301-1/+1
| | | | | | | | | | | | | | | Eric Lippert has a new blog that he keeps updating, update the link to that
* | | | | Merge #4231bors[bot]2020-04-305-14/+83
|\ \ \ \ \ | |/ / / / |/| | / / | | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | 4231: Fix a bunch of false-positives in join-lines r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | Fix a bunch of false-positives in join-linesAleksey Kladov2020-04-305-14/+83
|/ / /
* | | Merge #4153bors[bot]2020-04-304-13/+125
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4153: Add support for incremental text synchronization r=matklad a=lnicola Fixes #3762. This still needs a `ra_vfs` PR, but I want to know I'm on the right track. I tested the change and it didn't crash horribly, but YMMV. Co-authored-by: LaurenÈ›iu Nicola <[email protected]>
| * | | Add support for incremental text synchronizationLaurențiu Nicola2020-04-304-13/+125
| | | |
* | | | Merge #4227bors[bot]2020-04-306-81/+116
|\ \ \ \ | |_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4227: Report invalid, nested, multi-segment crate-paths r=matklad a=djrenren There was a bug in the previous path-validating code that didn't detect multi-segment paths that started with `crate`. ```rust // Successfully reported use foo::{crate}; // BUG: was not being reported use foo::{crate::bar}; ``` This was due to my confusion about path-associativity. That is, the path with no qualifier is the innermost path, not the outermost. I've updated the code with a lot of comments to explain what's going on. This bug was discovered when I found an erroneous `ok` test which I reported here: https://github.com/rust-analyzer/rust-analyzer/issues/4226 This test now fails and has been modified, hopefully in the spirit of the original test, to be correct. Sorry about submitting the bug in the first place! Co-authored-by: John Renner <[email protected]>
| * | | Report invalid, nested, multi-segment crate-pathsJohn Renner2020-04-306-81/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Specifically, things like: use foo::{crate::bar}; Are now being caught, when before we only caught: use foo::{crate};
* | | | Merge #4225bors[bot]2020-04-303-0/+39
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4225: Special-case try macro_rules r=matklad a=edwin0cheng Similar to #4221, but for `macro_rules! try {}` Co-authored-by: Edwin Cheng <[email protected]>
| * | | | Special-case try macro_rulesEdwin Cheng2020-04-303-0/+39
| |/ / /
* | | | Merge #4222bors[bot]2020-04-304-13/+194
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4222: Introduce C/C++ for Visual Studio Code extension as an alternative debug engine for Debug Code lens. r=matklad a=vsrs At the moment Debug Code Lens can use only one debug engine: lldb via [CodeLLDB](https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb) extension. This PR adds support of the debug engine from the [MS C++ tools](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools) extension, as well as the configuration option. If both extensions are installed, `CodeLLDB` will be used by default. Another new option `rust-analyzer.debug.sourceFileMap` allows, for example, to step into Rust std library during debugging. Works only with `MS C++ tools`. On Windows: ```json "rust-analyzer.debug.sourceFileMap": { "/rustc/4fb7144ed159f94491249e86d5bbd033b5d60550": "${env:USERPROFILE}/.rustup/toolchains/stable-x86_64-pc-windows-msvc/lib/rustlib/src/rust" } ``` On Linux: ```json "rust-analyzer.debug.sourceFileMap": { "/rustc/4fb7144ed159f94491249e86d5bbd033b5d60550": "~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust" } ``` Co-authored-by: vsrs <[email protected]>
| * | | fixed lint warningvsrs2020-04-301-1/+1
| | | |
| * | | Removed unnecessary extraArgs for cargo invocationvsrs2020-04-302-6/+3
| | | |
| * | | Fixed tsfmt and eslint errors.vsrs2020-04-302-19/+19
| | | |
| * | | pass Cargo errors to the Debug output channelvsrs2020-04-303-7/+19
| | | |
| * | | MS C++ tools on linuxvsrs2020-04-291-1/+2
| | | |
| * | | better configuration enum itemsvsrs2020-04-293-13/+16
| | | |
| * | | Configuration settings and source maps supportvsrs2020-04-294-10/+52
| | | |
| * | | ms-vscode.cpptools debugger support, initial version.vsrs2020-04-282-12/+138
| | | |
* | | | Merge #4223bors[bot]2020-04-302-92/+79
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4223: Allow to set env vars and pipe stdin via not_bash r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Allow to set env vars and pipe stdin via not_bashAleksey Kladov2020-04-302-92/+79
| | | | |
* | | | | Merge #4221bors[bot]2020-04-303-0/+52
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4221: Special-case try macro to better support 2015 edition r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Special-case try macro to better support 2015 editionAleksey Kladov2020-04-303-0/+52
|/ / / /
* | | | Merge #4219bors[bot]2020-04-301-33/+67
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4219: Avoid `rustup` invocation for non-rustup rust installation r=matklad a=oxalica Fix #4218 and #3243. Co-authored-by: oxalica <[email protected]>
| * | | | Avoid `rustup` invocation for non-rustup rust installationoxalica2020-04-301-33/+67
| | |/ / | |/| |
* | | | Merge #4210bors[bot]2020-04-302-0/+65
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4210: Include function qualifiers in signature r=matklad a=oxalica Fixes #2450 It seems there's no test for `ra_ide/display/{short_label,function_signature}`. I'm not sure how to setup it. Manually tested: <img width="428" alt="Screenshot_20200430_004434" src="https://user-images.githubusercontent.com/14816024/80622769-d6f1c200-8a7b-11ea-91f3-e94bfb2703c5.png"> Co-authored-by: oxalica <[email protected]>
| * | | | Add tests of showing function qualifiersoxalica2020-04-301-0/+25
| | | | |
| * | | | Include function qualifiers in signatureoxalica2020-04-291-0/+40
| |/ / /
* | | | Merge #4178bors[bot]2020-04-305-1/+121
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4178: Validate the location of `crate` in paths r=matklad a=djrenren **This solution does not fully handle `use` statements. See below** This pull requests implements simple validation of usages of the `crate` keyword in `Path`s. Specifically it validates that: - If a `PathSegment` is starts with the `crate` keyword, it is also the first segment of the `Path` - All other usages of `crate` in `Path`s are considered errors. This aligns with `rustc`'s rules. Unlike rustc this implementation does not issue a special error message in the case of `::crate` but it does catch the error. Furthermore, this change does not cover all error cases. Specifically the following is not caught: ```rust use foo::{crate} ``` This is because this check is context sensitive. From an AST perspective, `crate` is the root of the `Path`. Only by inspecting the full `UseItem` do we see that it is not in fact the root. This problem becomes worse because `UseTree`s are allowed to be arbitrarily nested: ```rust use {crate, {{crate, foo::{crate}}} ``` So this is a hard problem to solve without essentially a breadth-first search. In a traditional compiler, I'd say this error is most easily found during the AST -> HIR conversion pass but within rust-analyzer I'm not sure where it belongs. Under the implementation in this PR, such errors are ignored so we're *more correct* just not *entirely correct*. Co-authored-by: John Renner <[email protected]>
| * | | | Validate the location of `crate` in pathsJohn Renner2020-04-295-1/+121
| | |/ / | |/| |
* | | | Merge #4216bors[bot]2020-04-301-2/+4
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4216: docs(user): method chaining hints support r=flodiebold a=fannheyward https://github.com/fannheyward/coc-rust-analyzer/issues/177#issuecomment-621109410 <img width="490" alt="" src="https://user-images.githubusercontent.com/345274/80584717-acd0dd80-8a44-11ea-9505-c408a259a5b5.png"> Co-authored-by: Heyward Fann <[email protected]>
| * | | | docs(user): method chaining hints supportHeyward Fann2020-04-301-2/+4
|/ / / / | | | | | | | | | | | | https://github.com/fannheyward/coc-rust-analyzer/issues/177#issuecomment-621109410
* | | | Merge #4162bors[bot]2020-04-295-68/+402
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4162: Complete assoc. items on type parameters r=jonas-schievink a=jonas-schievink This is fairly messy and seems to leak a lot through the `ra_hir` abstraction (`TypeNs`, `AssocItemId`, ...), so I'd be glad for any advise for how to improve this. Co-authored-by: Jonas Schievink <[email protected]>
| * | | | if let -> matchJonas Schievink2020-04-291-4/+3
| | | | |
| * | | | ?Jonas Schievink2020-04-291-5/+1
| | | | |
| * | | | Use or-patterns moreJonas Schievink2020-04-291-10/+9
| | | | |
| * | | | Remove `.clone()`Jonas Schievink2020-04-291-8/+8
| | | | |
| * | | | Rename to associated_type_shorthand_candidatesJonas Schievink2020-04-293-29/+30
| | | | |
| * | | | Complete assoc. items on type parametersJonas Schievink2020-04-295-69/+408
|/ / / /
* | | | Merge #4212bors[bot]2020-04-291-2/+2
|\ \ \ \ | |_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | 4212: Fix Typos on features.md r=kjeremy a=lonesometraveler Co-authored-by: KENTARO OKUDA <[email protected]>
| * | | Fix Typos on features.mdKENTARO OKUDA2020-04-291-2/+2
|/ / /
* | | Merge #4119bors[bot]2020-04-294-65/+110
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4119: Cache proc-macro dlls r=matklad a=edwin0cheng This PR try to fix a deadlock in proc-macro srv by not unloading dlls. Currently we load and unload dlls for each request, however rustc TLS is leaky , such that if we do it a lot of times, all TLS index will be consumed and it will be deadlocked inside panic (it is because panic itself is using TLS too). Co-authored-by: Edwin Cheng <[email protected]>
| * | | Generate uniq nameEdwin Cheng2020-04-261-3/+11
| | | |