aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge #3864bors[bot]2020-04-061-1/+1
|\ | | | | | | | | | | | | | | 3864: Use log::info in trait_solve_query instead of eprintln r=edwin0cheng a=edwin0cheng cc @flodiebold Co-authored-by: Edwin Cheng <[email protected]>
| * Use log info in trait_solve_queryEdwin Cheng2020-04-061-1/+1
|/
* Merge pull request #3853 from matklad/cfAleksey Kladov2020-04-065-12/+9
|\ | | | | Make control token modifier less ambiguous
| * Make control token modifier less ambiguousAleksey Kladov2020-04-065-12/+9
| | | | | | | | | | | | | | | | | | In textmate, keyword.control is used for all kinds of things; in fact, the default scope mapping for keyword is keyword.control! So let's add a less ambiguous controlFlow modifier See Microsoft/vscode#94367
* | Merge #3843bors[bot]2020-04-062-11/+11
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 3843: Remove rustc_lexer dependency in favour of rustc-ap-rustc_lexer r=est31 a=est31 The latter is auto-published on a regular schedule (Right now weekly). See also https://github.com/alexcrichton/rustc-auto-publish Co-authored-by: est31 <[email protected]>
| * | Remove rustc_lexer dependency in favour of rustc-ap-rustc_lexerest312020-04-062-11/+11
| | | | | | | | | | | | The latter is auto-published on a regular schedule (Right now weekly).
* | | Merge #3829bors[bot]2020-04-061-12/+110
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3829: Adds to SSR match for semantically equivalent call and method call r=matklad a=mikhail-m1 #3186 maybe I've missed some corner cases, but it works in general Co-authored-by: Mikhail Modin <[email protected]>
| * | | Adds to SSR match for semantically equivalent call and method callMikhail Modin2020-04-021-12/+110
| | | |
* | | | Merge #3744bors[bot]2020-04-0612-158/+307
|\ \ \ \ | |_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | 3744: Upgrade Chalk r=matklad a=flodiebold Co-authored-by: Florian Diebold <[email protected]> Co-authored-by: Florian Diebold <[email protected]>
| * | | Upgrade Chalk againFlorian Diebold2020-04-0512-115/+198
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The big change here is counting binders, not variables (https://github.com/rust-lang/chalk/pull/360). We have to adapt to the same scheme for our `Ty::Bound`. It's mostly fine though, even makes some things more clear.
| * | | Upgrade ChalkFlorian Diebold2020-04-054-52/+118
| | | |
* | | | Merge pull request #3855 from edwin0cheng/add-back-deny-ccAleksey Kladov2020-04-061-5/+2
|\ \ \ \ | | | | | | | | | | Add back deny_c
| * | | | Add back deny_cEdwin Cheng2020-04-051-5/+2
| | | | |
* | | | | Merge #3859bors[bot]2020-04-051-2/+2
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3859: Update serde_json r=kjeremy a=kjeremy Grabs fix for https://github.com/serde-rs/json/issues/647 Co-authored-by: kjeremy <[email protected]>
| * | | | | Update serde_jsonkjeremy2020-04-051-2/+2
|/ / / / /
* | | | | Merge #3858bors[bot]2020-04-055-20/+28
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3858: Hide unit function return types r=flodiebold a=lnicola r? @flodiebold This might be a bit heavy-handed (e.g. `|| -> ()` to `||`), what do you think? Co-authored-by: Laurențiu Nicola <[email protected]>
| * | | | Hide unit fn return typesLaurențiu Nicola2020-04-055-20/+28
|/ / / /
* | | | Merge #3857bors[bot]2020-04-052-1/+31
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3857: Fix inference of function pointer return types r=flodiebold a=lnicola Fixes #3852. r? @flodiebold Co-authored-by: Laurențiu Nicola <[email protected]>
| * | | Fix inference of function pointer return typesLaurențiu Nicola2020-04-052-1/+31
|/ / /
* | | Merge #3849bors[bot]2020-04-041-10/+10
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3849: Cargo update r=kjeremy a=kjeremy Co-authored-by: kjeremy <[email protected]>
| * | | Cargo updatekjeremy2020-04-041-10/+10
|/ / /
* | | Merge #3848bors[bot]2020-04-042-53/+0
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3848: Remove unused dependencies r=kjeremy a=est31 Found by cargo-udeps Co-authored-by: est31 <[email protected]>
| * | | Remove unused dependenciesest312020-04-042-53/+0
| | |/ | |/|
* | | Merge #3844bors[bot]2020-04-041-0/+5
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3844: vscode: restore removed default values r=matklad a=Veetaha After refactoring the config we forgot to set defaults for some properties like workspaceLoaded, callInfo.full, etc. This commit restored them to being turned on by defult, as well added defaults for other props to be more explicit on their defualt value. cc @matklad Co-authored-by: veetaha <[email protected]>
| * | | vscode: restore removed default valuesveetaha2020-04-041-0/+5
| |/ / | | | | | | | | | | | | | | | | | | | | | After refactoring the config we forgot to set defaults for some properties like workspaceLoaded, callInfo.full, etc. This commit restored them to being turned on by defult, as well added defaults for other props to be more explicit on their defualt value.
* | | Merge #3845bors[bot]2020-04-041-9/+8
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3845: Simplify config r=matklad a=Veetaha Co-authored-by: veetaha <[email protected]>
| * | | Remove explicit generic type parameterveetaha2020-04-041-1/+1
| | | |
| * | | Simplify configveetaha2020-04-041-9/+8
| |/ /
* | | Merge #3846bors[bot]2020-04-041-0/+2
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 3846: vscode: log server binary path r=matklad a=Veetaha Co-authored-by: veetaha <[email protected]>
| * | vscode: log server binary pathveetaha2020-04-041-0/+2
|/ /
* | Merge #3840bors[bot]2020-04-037-127/+236
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3840: Add parens for enums r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | Add parens for enumsAleksey Kladov2020-04-034-46/+175
| | |
| * | Generalize call parenthesis insertionAleksey Kladov2020-04-031-27/+46
| | |
| * | Remove the second code-path for completing names in patternsAleksey Kladov2020-04-034-70/+31
| | |
* | | Merge #3837bors[bot]2020-04-031-0/+1
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | 3837: Include grammar for syntax trees into vsix r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | Include grammar for syntax trees into vsixAleksey Kladov2020-04-031-0/+1
|/ /
* | Merge #3836bors[bot]2020-04-038-30/+100
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3836: Macro patterns are not confused with expressions. r=matklad a=matklad We treat macro calls as expressions (there's appropriate Into impl), which causes problem if there's expresison and non-expression macro in the same node (like in the match arm). We fix this problem by nesting macor patterns into another node (the same way we nest path into PathExpr or PathPat). Ideally, we probably should add a similar nesting for macro expressions, but that needs some careful thinking about macros in blocks: `{ am_i_expression!() }`. bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | Macro patterns are not confused with expressions.Aleksey Kladov2020-04-037-17/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We treat macro calls as expressions (there's appropriate Into impl), which causes problem if there's expresison and non-expression macro in the same node (like in the match arm). We fix this problem by nesting macor patterns into another node (the same way we nest path into PathExpr or PathPat). Ideally, we probably should add a similar nesting for macro expressions, but that needs some careful thinking about macros in blocks: `{ am_i_expression!() }`.
| * | CleanupsAleksey Kladov2020-04-032-14/+13
|/ /
* | Merge #3834bors[bot]2020-04-031-3/+6
|\ \ | | | | | | | | | | | | | | | | | | | | | 3834: Set semantic tokens supertypes r=matklad a=matklad bors r+ Co-authored-by: Aleksey Kladov <[email protected]>
| * | Set semantic tokens supertypesAleksey Kladov2020-04-031-3/+6
| | |
* | | Merge #3800bors[bot]2020-04-035-2/+164
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3800: Introduce ra_proc_macro_srv r=matklad a=edwin0cheng This PR add preliminary for server side of proc macro : 1. Add crate setup 2. IO for server side Co-authored-by: Edwin Cheng <[email protected]>
| * | Add doc comment on main.rsEdwin Cheng2020-04-031-0/+2
| | |
| * | Introduce ra_proc_macro_srvEdwin Cheng2020-04-035-2/+162
|/ /
* | Merge pull request #3833 from edwin0cheng/remove-deny-cAleksey Kladov2020-04-031-2/+5
|\ \ | | | | | | Remove deny_c in CI
| * | Remove deny_c in CIEdwin Cheng2020-04-031-2/+5
|/ /
* | Merge #3746bors[bot]2020-04-035-0/+868
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3746: Add create_function assist r=flodiebold a=TimoFreiberg The function part of #3639, creating methods will come later - [X] Function arguments - [X] Function call arguments - [x] Method call arguments - [x] Literal arguments - [x] Variable reference arguments - [X] Migrate to `ast::make` API Done, but there are some ugly spots. Issues to handle in another PR: - function reference arguments: Their type isn't printed properly right now. The "insert explicit type" assist has the same issue and this is probably a relatively rare usecase. - generating proper names for all kinds of argument expressions (if, loop, ...?) Without this, it's totally possible for the assist to generate invalid argument names. I think the assist it's already helpful enough to be shipped as it is, at least for me the main usecase involves passing in named references. Besides, the Rust tooling ecosystem is immature enough that some janky behaviour in a new assist probably won't scare anyone off. - select the generated placeholder body so it's a bit easier to overwrite it - create method (`self.foo<|>(..)` or `some_foo.foo<|>(..)`) instead of create_function. The main difference would be finding (or creating) the impl block and inserting the `self` argument correctly - more specific default arg names for literals. So far, every generated argument whose name can't be taken from the call site is called `arg` (with a number suffix if necessary). - creating functions in another module of the same crate. E.g. when typing `some_mod::foo<|>(...)` when in `lib.rs`, I'd want to have `foo` generated in `some_mod.rs` and jump there. Issues: the mod could exist in `some_mod.rs`, in `lib.rs` as `mod some_mod`, or inside another mod but be imported via `use other_mod::some_mod`. - refer to arguments of the generated function with a qualified path if the types aren't imported yet (alternative: run autoimport. i think starting with a qualified path is cleaner and there's already an assist to replace a qualified path with an import and an unqualified path) - add type arguments of the arguments to the generated function - Autocomplete functions with information from unresolved calls (see https://github.com/rust-analyzer/rust-analyzer/pull/3746#issuecomment-605281323) Issues: see https://github.com/rust-analyzer/rust-analyzer/pull/3746#issuecomment-605282542. The unresolved call could be anywhere. But just offering this autocompletion for unresolved calls in the same module would already be cool. Co-authored-by: Timo Freiberg <[email protected]>
| * | Use ast::make API in add_function assistTimo Freiberg2020-04-012-67/+73
| | |
| * | Add create_function assistTimo Freiberg2020-04-014-0/+862
| | |
* | | Merge #3814bors[bot]2020-04-034-1/+230
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | 3814: Add impl From for enum variant assist r=flodiebold a=mattyhall Basically adds a From impl for tuple enum variants with one field. It was recommended to me on the zulip to maybe try using the trait solver, but I had trouble with that as, although it could resolve the trait impl, it couldn't resolve the variable unambiguously in real use. I'm also unsure of how it would work if there were already multiple From impls to resolve - I can't see a way we could get more than one solution to my query. Fixes #3766 Co-authored-by: Matthew Hall <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-17 00:06:03 +0100