aboutsummaryrefslogtreecommitdiff
path: root/crates
Commit message (Collapse)AuthorAgeFilesLines
* Merge #3746bors[bot]2020-04-034-0/+842
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-013-0/+836
| |
* | 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]>
| * | Cleanup checking for existing impls in impl From assistMatthew Hall2020-04-022-48/+24
| | | | | | | | | | | | | | | Use the trait solver to check if there's an existing implementation of From<type_in_enum_variant> for the enum.
| * | Add impl From for enum variant assistMatthew Hall2020-04-014-2/+255
| | | | | | | | | | | | | | | | | | Basically adds a From impl for tuple enum variants with one field. Added to cover the fairly common case of implementing your own Error that can be created from another one, although other use cases exist.
* | | Apply cargo xtask formatveetaha2020-04-021-1/+0
| | |
* | | Migrate to privacy as per review commetsveetaha2020-04-026-15/+25
| | |
* | | Less mutabilityveetaha2020-04-021-19/+23
| | |
* | | Migrate to iters some moreveetaha2020-04-021-18/+11
| | |
* | | Migrate to iteratorsveetaha2020-04-021-15/+3
| | |
* | | Simpify workspace handlingveetaha2020-04-027-83/+63
| | |
* | | Don't clone where you can copyveetaha2020-04-021-1/+1
| | |
* | | Merge #3811bors[bot]2020-04-025-3/+104
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3811: Add inference for literal and range patterns r=kjeremy a=flodiebold (cc @JoshMcguigan ) Co-authored-by: Florian Diebold <[email protected]>
| * | | Add inference for literal and range patternsFlorian Diebold2020-04-015-3/+104
| | |/ | |/|
* | | Allow fully overriding check and fmt commandsAleksey Kladov2020-04-021-2/+19
| | |
* | | Remove vscode_lldb settingAleksey Kladov2020-04-022-20/+14
| | |
* | | SiplifyAleksey Kladov2020-04-022-7/+5
| | |
* | | Lean onto default implementation of configsAleksey Kladov2020-04-023-11/+16
| | |
* | | New config in package.jsonAleksey Kladov2020-04-021-26/+41
| | |
* | | Reorder fieldsAleksey Kladov2020-04-021-44/+47
| | |
* | | Merge #3820bors[bot]2020-04-024-87/+3
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3820: Remove old syntax highlighting r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | Remove old syntax highlightingAleksey Kladov2020-04-024-87/+3
| |/ /
* / / Unique package by name and version.o0Ignition0o2020-04-021-4/+5
|/ / | | | | | | | | This commit is a fixup of a bug I introduced by using a PackageId to refer to a crate when its name conflicts with a dependency. It turns out the package id currently is `name version path` while cargo expects `name:version` as argument.
* | Merge #3806bors[bot]2020-04-012-3/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3806: lower bool literal value r=flodiebold a=JoshMcguigan Following up on #3805, this PR adds the literal value to `ast::LiteralKind` so when we lower we can use the actual value from the source code rather than the default value for the type. Ultimately I plan to use this for exhaustiveness checking in #3706. I didn't include this in the previous PR because I wasn't sure if it made sense to add this information to `ast::LiteralKind` or provide some other mechanism to get this from `ast::Literal`. For now I've only implemented this for boolean literals, but I think it could be easily extended to other types. A possible exception to this are string literals, since we may not want to clone around an owned string to hold onto in `ast::LiteralKind`, and it'd be nice to avoid adding a generic lifetime as well. Perhaps we won't ever care about the actual value of a string literal? Co-authored-by: Josh Mcguigan <[email protected]>
| * | lower bool literal with the value from source code rather than default bool ↵Josh Mcguigan2020-04-012-3/+4
| | | | | | | | | | | | value
* | | Fix pointer syntaxAleksey Kladov2020-04-012-30/+36
| | |
* | | Centralize defaultsAleksey Kladov2020-04-012-18/+6
| | |
* | | Reduce scope of deserializationAleksey Kladov2020-04-015-21/+16
| | |
* | | Centralize client capabilitiesAleksey Kladov2020-04-016-17/+21
| | |
* | | Centralize all configAleksey Kladov2020-04-019-328/+151
| | |
* | | Move all config to configAleksey Kladov2020-04-013-7/+17
| | |
* | | Reduce feature flagsAleksey Kladov2020-04-014-52/+48
| | |
* | | Merge #3807bors[bot]2020-04-014-60/+94
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3807: Generalize rustfmt config r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | Move config to config.rsAleksey Kladov2020-04-014-72/+77
| | | |
| * | | Generalize rustfmt configAleksey Kladov2020-04-013-11/+40
| |/ /
* | | Merge #3797bors[bot]2020-04-011-10/+23
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | 3797: Don't show chaining hints for record literals and unit structs r=matklad a=lnicola Fixes #3796 r? @Veetaha Co-authored-by: LaurenÈ›iu Nicola <[email protected]>
| * | Don't show chaining hints for record literals and unit structsLaurențiu Nicola2020-04-011-10/+23
| | |
* | | Merge #3805bors[bot]2020-04-011-21/+33
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3805: lower literal patterns r=JoshMcguigan a=JoshMcguigan While working on #3706 I discovered literal patterns weren't being lowered. This PR implements that lowering. Questions for reviewers: 1. This re-uses the existing conversion from `ast::LiteralKind` to `Literal`, but `ast::LiteralKind` doesn't include information about the actual value of the literal, which causes `Literal` to be created with the default value for the type (rather than the actual value in the source code). Am I correct in thinking that we'd eventually want to change things in such a way that we could initialize the `Literal` with the actual literal value? Is there an existing issue for this, or else perhaps I should create one to discuss how it should be implemented? My main question would be whether `ast::LiteralKind` should be extended to hold the actual value, or if we should provide some other way to get that information from `ast::Literal`? 2. I couldn't find tests which directly cover this, but it does seem to work in #3706. Do we have unit tests for this lowering code? 3. I'm not sure why `lit.literal()` returns an `Option`. Is returning a `Pat::Missing` in the `None` case the right thing to do? 4. I was basically practicing type-system driven development to figure out the transformation from `ast::Pat::LiteralPat` to `Pat::Lit`. I don't have an immediate question here, but I just wanted to ensure this section is looked at closely during review. Co-authored-by: Josh Mcguigan <[email protected]>
| * | | lower literal patternsJosh Mcguigan2020-04-011-21/+33
| | | |
* | | | Simplify error handingAleksey Kladov2020-04-011-38/+17
| | | |
* | | | Generalize FlycheckconfigAleksey Kladov2020-04-012-15/+21
| | | |
* | | | Merge #3779bors[bot]2020-04-014-363/+413
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3779: Complete only missing fields in pats r=matklad a=SomeoneToIgnore A follow-up for https://github.com/rust-analyzer/rust-analyzer/pull/3694 Same name vs string [issue](https://github.com/rust-analyzer/rust-analyzer/pull/3694#discussion_r396986819) persists here, now I'm able to obtain `ast::Name`, but I see no way to convert it into `hir::Name` or vice versa. Co-authored-by: Kirill Bulatov <[email protected]>
| * | | | Unite record completion logic into a single moduleKirill Bulatov2020-04-014-450/+413
| | | | |
| * | | | Split draftKirill Bulatov2020-04-013-59/+85
| | | | |
| * | | | Complete only missing fields in patsKirill Bulatov2020-04-011-1/+62
| |/ / /
* | | | Merge #3803bors[bot]2020-04-013-39/+35
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3803: Cleanup r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | CleanupAleksey Kladov2020-04-013-39/+35
| |/ / /
* | | | Merge #3765bors[bot]2020-04-011-26/+90
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | 3765: Adds sort for RecordLit comparison in SSR r=edwin0cheng a=mikhail-m1 an item from #3186 Co-authored-by: Mikhail Modin <[email protected]>
| * | | Adds sort for RecordLit comparison in SSRMikhail Modin2020-04-011-26/+90
| | |/ | |/|
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-24 04:47:32 +0000