aboutsummaryrefslogtreecommitdiff
path: root/crates
Commit message (Collapse)AuthorAgeFilesLines
* Silence "file out of workspace" errorsAleksey Kladov2020-03-092-3/+12
| | | | | We really should fix this limitation of the VFS, but it's some way off at the moment, so let's just silence the user-visible error for now.
* Merge #3513bors[bot]2020-03-0913-42/+527
|\ | | | | | | | | | | | | | | | | | | | | 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-084-39/+43
| |
| * Remove TODOsFlorian Diebold2020-03-071-5/+6
| |
| * 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-073-1/+54
| |
| * Try to complete within macrosFlorian Diebold2020-03-078-38/+338
| |
* | Merge #3516bors[bot]2020-03-094-19/+217
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-083-22/+124
| | |
| * | Handle visibility for path completion (not in all cases yet)Florian Diebold2020-03-082-5/+51
| | |
| * | Handle visibility in method call completionFlorian Diebold2020-03-073-4/+54
| |/
* | Merge #3518bors[bot]2020-03-095-37/+213
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3518: Add parse_to_token_tree r=matklad a=edwin0cheng This PR introduce a function for parsing `&str` to `tt::TokenTree`: ```rust // Convert a string to a `TokenTree` pub fn parse_to_token_tree(text: &str) -> Option<(tt::Subtree, TokenMap)> { ```` Co-authored-by: Edwin Cheng <[email protected]>
| * | Add parse_to_token_treeEdwin Cheng2020-03-085-37/+213
| |/
* | Merge #3524bors[bot]2020-03-091-0/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3524: Ignore client-specific notifications r=matklad a=matklad closes #3523 bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | Ignore client-specific notificationsAleksey Kladov2020-03-091-0/+3
| |/ | | | | | | closes #3523
* / Omit unit struct hintsKirill Bulatov2020-03-081-0/+32
|/
* Prevent include! macro include itselfEdwin Cheng2020-03-072-1/+24
|
* Fix test and add more commentEdwin Cheng2020-03-071-1/+4
|
* Use a not so dummy implementation of env macroEdwin Cheng2020-03-072-1/+28
|
* Normalize waiting queries namesAleksey Kladov2020-03-067-31/+26
|
* Don't reuse the Chalk solverFlorian Diebold2020-03-064-95/+29
| | | | | This slows down analysis-stats a bit (~5% in my measurement), but improves incremental checking a lot because we can reuse trait solve results.
* Merge #3499bors[bot]2020-03-063-38/+93
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 3499: Resolve `Self::AssocTy` in impls r=matklad a=flodiebold To do this we need to carry around the original resolution a bit, because `Self` gets resolved to the actual type immediately, but you're not allowed to write the equivalent type in a projection. (I tried just comparing the projection base type with the impl self type, but that seemed too dirty.) This is basically how rustc does it as well. Fixes #3249. Co-authored-by: Florian Diebold <[email protected]>
| * Resolve `Self::AssocTy` in implsFlorian Diebold2020-03-063-38/+93
| | | | | | | | | | | | | | | | | | | | To do this we need to carry around the original resolution a bit, because `Self` gets resolved to the actual type immediately, but you're not allowed to write the equivalent type in a projection. (I tried just comparing the projection base type with the impl self type, but that seemed too dirty.) This is basically how rustc does it as well. Fixes #3249.
* | Don't creat public APIs with typosAleksey Kladov2020-03-062-2/+2
| |
* | Concise mode for parameter hintsAleksey Kladov2020-03-063-15/+23
| | | | | | | | | | This works around VS Code bug where it tries to cram everything in a tiny popup, and brings experience closer to Intellij.
* | Trigger parameter info automaticallyAleksey Kladov2020-03-063-0/+26
| | | | | | | | See https://github.com/Microsoft/vscode/issues/64023
* | Feature flag for arg snippetsAleksey Kladov2020-03-062-4/+14
| |
* | Fix comment orderAleksey Kladov2020-03-061-2/+2
|/
* Allow specifying additional info on call to profileAleksey Kladov2020-03-063-21/+52
|
* Less confusing profile namesAleksey Kladov2020-03-064-4/+4
|
* Merge #3494bors[bot]2020-03-064-19/+107
|\ | | | | | | | | | | | | | | | | | | | | | | 3494: Implement include macro r=matklad a=edwin0cheng This PR implement builtin `include` macro. * It does not support include as expression yet. * It doesn't consider `env!("OUT_DIR")` yet. Co-authored-by: Edwin Cheng <[email protected]>
| * Implment include macroEdwin Cheng2020-03-064-19/+107
| |
* | Merge #3493bors[bot]2020-03-061-0/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3493: make::use_item r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | make::use_itemAleksey Kladov2020-03-061-0/+4
| | |
* | | Merge #3490bors[bot]2020-03-063-1/+95
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 3490: Support aliases and Self in struct literals r=matklad a=flodiebold Fixes #3306. Co-authored-by: Florian Diebold <[email protected]>
| * | Support aliases and Self in struct literalsFlorian Diebold2020-03-063-1/+95
| | | | | | | | | | | | Fixes #3306.
* | | Merge #3492bors[bot]2020-03-062-13/+4
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | 3492: Simplify creation of `T[,]` r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | Simplify creation of `T[,]`Aleksey Kladov2020-03-062-13/+4
| | |
* | | Explicitly remember desugard patsAleksey Kladov2020-03-062-6/+10
| | |
* | | Explicitly remember desugard exprsAleksey Kladov2020-03-062-18/+19
| | |
* | | Source map returns a resultAleksey Kladov2020-03-066-18/+26
|/ / | | | | | | cc #2236
* / Rerail split_import API onto ASTAleksey Kladov2020-03-063-19/+72
|/ | | | | The code is more verbose and less efficient now, but should be reusable in add_import context as well
* Merge #3483bors[bot]2020-03-063-66/+73
|\ | | | | | | | | | | | | | | 3483: Unfold groups with single assists into plain assists r=matklad a=SomeoneToIgnore A follow-up of https://github.com/rust-analyzer/rust-analyzer/pull/3120/files#r378788698 , made to show more detailed label when the assist group contains a single element Co-authored-by: Kirill Bulatov <[email protected]>
| * Unfold groups with single assists into plain assistsKirill Bulatov2020-03-053-66/+73
| |
* | Merge #3482bors[bot]2020-03-062-1/+57
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3482: Fix regression from #3451 r=matklad a=edwin0cheng There is a regression from #3451 such that the following code has failed to parse in raw item collecting phase: ```rust macro_rules! with_std { ($($i:item)*) => ($(#[cfg(feature = "std")]$i)*) } with_std! { mod macros; mod others; } ``` ### Rationale We always assume the last token of an statement will not end with a whitespace, which is true. It is because in parsing phase, we always emit `SyntaxNode` before any whitespace. Such that in various parts of RA code, we solely check the semi-colon by using `SyntaxNode::last_child_token() == ";"` . However, in #3451, we insert some whitespaces between puncts such that we broke above assumption. This PR fixed this bug by make sure we don't add any whitespace if it is a semicolon. Co-authored-by: Edwin Cheng <[email protected]>
| * fix regression from #3451Edwin Cheng2020-03-052-1/+57
| |