aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_ide/src
Commit message (Collapse)AuthorAgeFilesLines
...
* | | | Implement dummy assert macroEdwin Cheng2020-03-111-6/+2
| |/ / |/| |
* | | Continue multiline non-doc comment blocksAleksey Kladov2020-03-111-3/+35
| | |
* | | Split on enter testsAleksey Kladov2020-03-111-15/+28
| | |
* | | Move on enter to a separate moduleAleksey Kladov2020-03-112-154/+177
| | |
* | | Merge #3549bors[bot]2020-03-113-0/+4
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3549: Implement env! macro r=matklad a=edwin0cheng This PR implements `env!` macro by adding following things: 1. Added `additional_outdirs` settings in vscode. (naming to be bikeshed) 2. Added `ExternSourceId` which is a wrapping for SourceRootId but only used in extern sources. It is because `OUT_DIR` is not belonged to any crate and we have to access it behind an `AstDatabase`. 3. This PR does not implement the `OUT_DIR` parsing from `cargo check`. I don't have general design about this, @kiljacken could we reuse some cargo watch code for that ? ~~Block on [#3536]~~ PS: After this PR , we (kind of) completed the `include!(concat!(env!('OUT_DIR'), "foo.rs")` macro call combo. [Exodia Obliterate!](https://www.youtube.com/watch?v=RfqNH3FoGi0) Co-authored-by: Edwin Cheng <[email protected]>
| * | | Add extern sourceEdwin Cheng2020-03-113-0/+4
| | | |
* | | | Merge #3555bors[bot]2020-03-1116-40/+93
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3555: Introduce completion test utils r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Introduce completion test utilsAleksey Kladov2020-03-1116-48/+49
| | | | |
| * | | | Add a test for disabled argument snippetsAleksey Kladov2020-03-113-5/+57
| | |/ / | |/| |
* | | | Merge #3542bors[bot]2020-03-111-21/+187
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3542: Renames work on struct field shorthands r=matklad a=m-n When renaming either a local or a struct field, struct field shorthands are now renamed correctly. Happy to refactor this if it doesn't fit the design of the code. Thanks for adding the suggestion of where to start on the issue. I wasn't sure if I should also look at the behavior of renaming when placing the cursor at the field shorthand; the following describes the behavior with this patch: ```rust #[test] fn test_rename_field_shorthand_for_unspecified() { // when renaming a shorthand, should we have a way to specify // between renaming the field and the local? // // If not is this the correct default? test_rename( r#" struct Foo { i: i32, } impl Foo { fn new(i: i32) -> Self { Self { i<|> } } } "#, "j", r#" struct Foo { i: i32, } impl Foo { fn new(j: i32) -> Self { Self { i: j } } } "#, ); } ``` Resolves #3431 Co-authored-by: Matt Niemeir <[email protected]>
| * | | find_usages limited to actual usages againMatt Niemeir2020-03-111-0/+70
| | | |
| * | | Renaming a local renames struct field shorthandMatt Niemeir2020-03-101-5/+43
| | | |
| * | | Struct field rename renames field in constructor field shorthandMatt Niemeir2020-03-101-21/+79
| | |/ | |/|
* | | Fix completion with a partially unknown typeFlorian Diebold2020-03-101-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To test whether the receiver type matches for the impl, we unify the given self type (in this case `HashSet<{unknown}>`) with the self type of the impl (`HashSet<?0>`), but if the given self type contains Unknowns, they won't be unified with the variables in those places. So we got a receiver type that was different from the expected one, and concluded the impl doesn't match. The fix is slightly hacky; if after the unification, our variables are still there, we make them fall back to Unknown. This does make some sense though, since we don't want to 'leak' the variables. Fixes #3547.
* | | Move FeatureFlagsAleksey Kladov2020-03-101-13/+3
| | |
* | | Pull completion options up to the rust-analyzerAleksey Kladov2020-03-102-15/+7
| | |
* | | Introduce CompletionOptionsAleksey Kladov2020-03-106-18/+48
| |/ |/|
* | Merge pull request #3506 from slyngbaek/3183Aleksey Kladov2020-03-101-16/+128
|\ \ | |/ |/| Next steps in assoc item completion #3183
| * Switch to explicit offsets for impl_defSteffen Lyngbaek2020-03-091-26/+11
| | | | | | | | Blacklists are prone to more errors
| * Clean up completion matching.Steffen Lyngbaek2020-03-091-24/+53
| | | | | | | | - Add test to ensure nested completions don't happen
| * Don't allow nested completionsSteffen Lyngbaek2020-03-081-13/+18
| |
| * Next steps in assoc item completion #3183Steffen Lyngbaek2020-03-071-6/+99
| | | | | | | | | | | | | | | | Allow trait autocompletions for unimplemented associated fn's, types, and consts without using explicit keywords before hand (fn, type, const). The sequel to #3108.
* | Use `Index` for CrateGraphAleksey Kladov2020-03-092-3/+3
| |
* | Merge #3519bors[bot]2020-03-095-40/+111
|\ \ | | | | | | | | | | | | | | | | | | | | | 3519: Show mod path on hover r=matklad a=SomeoneToIgnore Closes #1064 Co-authored-by: Kirill Bulatov <[email protected]>
| * | Less abstract CrateData apiKirill Bulatov2020-03-092-4/+4
| | |
| * | Consider crate declaration namesKirill Bulatov2020-03-084-33/+29
| | |
| * | Show mod path in hover tooltipKirill Bulatov2020-03-072-29/+104
| |/
* | Merge #3513bors[bot]2020-03-099-36/+421
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3513: Completion in macros r=matklad a=flodiebold I experimented a bit with completion in macros. It's kind of working, but there are a lot of rough edges. - I'm trying to expand the macro call with the inserted fake token. This requires some hacky additions on the HIR level to be able to do "hypothetical" expansions. There should probably be a nicer API for this, if we want to do it this way. I'm not sure whether it's worth it, because we still can't do a lot if the original macro call didn't expand in nearly the same way. E.g. if we have something like `println!("", x<|>)` the expansions will look the same and everything is fine; but in that case we could maybe have achieved the same result in a simpler way. If we have something like `m!(<|>)` where `m!()` doesn't even expand or expands to something very different, we don't really know what to do anyway. - Relatedly, there are a lot of cases where this doesn't work because either the original call or the hypothetical call doesn't expand. E.g. if we have `m!(x.<|>)` the original token tree doesn't parse as an expression; if we have `m!(match x { <|> })` the hypothetical token tree doesn't parse. It would be nice if we could have better error recovery in these cases. Co-authored-by: Florian Diebold <[email protected]>
| * | Move hypothetical expansion to hir_expandFlorian Diebold2020-03-081-1/+5
| | |
| * | Fix CompletionContext module field (by removing it)Florian Diebold2020-03-073-8/+6
| | | | | | | | | | | | | | | Two uses only needed the crate; one was wrong and should use the module from the scope instead.
| * | Add some sanity checksFlorian Diebold2020-03-071-1/+10
| | |
| * | Fix record pattern completionFlorian Diebold2020-03-073-1/+30
| | |
| * | Fix record literal completionFlorian Diebold2020-03-072-3/+33
| | |
| * | Fix range for postfix snippetsFlorian Diebold2020-03-071-2/+63
| | |
| * | Add more testsFlorian Diebold2020-03-072-0/+51
| | |
| * | Try to complete within macrosFlorian Diebold2020-03-074-27/+230
| |/
* | Merge #3516bors[bot]2020-03-092-4/+139
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 3516: Handle visibility in more cases in completion r=matklad a=flodiebold This means we don't show private items when completing paths or method calls. We might want to show private items if we can edit their definition and provide a "make public" assist, but I feel like we'd need better sorting of completion items for that, so they can be not shown or sorted to the bottom by default. Until then, they're usually more of a distraction to me. Co-authored-by: Florian Diebold <[email protected]>
| * | Handle visibility for assoc item path completion as wellFlorian Diebold2020-03-081-2/+65
| | |
| * | Handle visibility for path completion (not in all cases yet)Florian Diebold2020-03-081-4/+40
| | |
| * | Handle visibility in method call completionFlorian Diebold2020-03-071-1/+37
| |/
* / Omit unit struct hintsKirill Bulatov2020-03-081-0/+32
|/
* Don't creat public APIs with typosAleksey Kladov2020-03-061-1/+1
|
* Trigger parameter info automaticallyAleksey Kladov2020-03-062-0/+16
| | | | See https://github.com/Microsoft/vscode/issues/64023
* Feature flag for arg snippetsAleksey Kladov2020-03-061-4/+13
|
* Fix comment orderAleksey Kladov2020-03-061-2/+2
|
* Support aliases and Self in struct literalsFlorian Diebold2020-03-061-0/+27
| | | | Fixes #3306.
* Prime open files on loadAleksey Kladov2020-03-052-0/+20
|
* Merge #3442bors[bot]2020-03-041-13/+45
|\ | | | | | | | | | | | | | | | | | | | | 3442: Skip self param when completing methods r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * Skip self param when completing methodsAleksey Kladov2020-03-041-13/+45
| |
* | Cleanup APIAleksey Kladov2020-03-043-6/+4
| |
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-12 01:11:34 +0000