aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_syntax
Commit message (Collapse)AuthorAgeFilesLines
* Convert to TODOs to FIXMEs as per matkladveetaha2020-05-121-4/+2
|
* Revert "Remove MacroStmts as per edwin0cheng" (cc @edwin0cheng) and add a ↵veetaha2020-05-121-0/+32
| | | | | | | | | | fixme to document it. This reverts commit 7a49165f5d5c8186edd04f874eae8a98e39d3df6. MacroStmts ast node is not used by itself, but it pertains to SyntaxNodeKind MACRO_STMTS that is used by ra_paser, so even tho the node itself is not used, it is better to keep it with a FIXME to actually add a doc comment when it becomes useful.
* Add a doc comment on the difference between Name and NameRef ast nodesveetaha2020-05-121-1/+16
|
* Resolve TODO about macro 2.0 defveetaha2020-05-101-6/+4
|
* Fix typoveetaha2020-05-101-1/+1
|
* Carify on a semicolon in macro callveetaha2020-05-101-1/+6
|
* Resolve TODO about curly-braced constructions in expression statementveetaha2020-05-101-1/+3
|
* Resolve todos about refs and empty statementsveetaha2020-05-101-4/+4
|
* Converted TODO about MacroItems to FIXME as per edwin0chengveetaha2020-05-101-6/+2
|
* Verified ConstArg example, waiting for response on what `=` sign pertains toveetaha2020-05-101-1/+1
|
* Correcy use tree and type args docsveetaha2020-05-101-3/+3
|
* Correct `use` cannot have type args as per flodieboldveetaha2020-05-101-1/+1
|
* Correct path docs and add colon2 token to Path ast nodeveetaha2020-05-101-8/+14
|
* Add example with const in TypeBound as per flodieboldveetaha2020-05-101-1/+1
|
* Properly document const impl as per flodieboldveetaha2020-05-101-2/+2
|
* Remove MacroStmts as per edwin0chengveetaha2020-05-101-32/+0
|
* Add proper docs for TokenTree as per edwin0chengveetaha2020-05-101-1/+2
|
* Run codegen of ast types with documentationveetaha2020-05-101-138/+1345
|
* unindent -> dedentAleksey Kladov2020-05-091-1/+1
|
* More fluent indent APIAleksey Kladov2020-05-091-13/+13
|
* Use more natural signature for Edit::applyAleksey Kladov2020-05-052-6/+11
|
* Rename AtomTextEdit -> IndelAleksey Kladov2020-05-053-18/+18
|
* Rename ImplItem to AssocItemEdwin Cheng2020-05-052-21/+21
|
* Add documents owner for ImplDef and SourceFileEdwin Cheng2020-05-031-0/+2
|
* Fix the extension methodKirill Bulatov2020-05-021-1/+1
|
*-. Merge #4207 #4253bors[bot]2020-05-021-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4207: Add unwrap block assist #4156 r=matklad a=bnjjj close issue #4156 4253: Remove `workspaceLoaded` setting r=matklad a=eminence The `workspaceLoaded` notification setting was originally designed to control the display of a popup message that said: "workspace loaded, {} rust packages" This popup was removed and replaced by a much sleeker message in the VSCode status bar that provides a real-time status while loading: rust-analyzer: {}/{} packages This was done as part of #3587 The change in this PR simply renames this setting from `workspaceLoaded` to `progress` to better describe what it actually controls. At the moment, the only type of progress message that is controlled by this setting is the initial load messages, but in theory other messages could also be controlled by this setting. Reviewer notes: * If we didn't like the idea of causing minor breaking to user's config, we could keep the setting name as `workspaceLoaded` * I think we can now close both #2719 and #3176 since the notification dialog in question no longer exists (actually I think you can close those issues even if you reject this PR 😄 ) Co-authored-by: Benjamin Coenen <[email protected]> Co-authored-by: Andrew Chin <[email protected]>
| * \ Merge branch 'master' of github.com:rust-analyzer/rust-analyzerBenjamin Coenen2020-05-021-0/+4
| |\ \
| * \ \ Merge branch 'master' of github.com:rust-analyzer/rust-analyzerBenjamin Coenen2020-05-02200-10752/+10539
| |\ \ \
| * \ \ \ Merge branch 'master' of github.com:rust-analyzer/rust-analyzerBenjamin Coenen2020-05-0114-78/+296
| |\ \ \ \
| * | | | | Add unwrap block assist #4156Benjamin Coenen2020-04-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
* | | | | | Fix parsing of blocks without `{`Aleksey Kladov2020-05-025-25/+78
| |_|_|/ / |/| | | |
* | | | | Merge #4234bors[bot]2020-05-021-0/+4
|\ \ \ \ \ | |_|_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4234: Support local_inner_macros r=jonas-schievink a=edwin0cheng This PR implements `#[macro_export(local_inner_macros)]` support. Note that the rustc implementation is quite [hacky][1] too. :) [1]: https://github.com/rust-lang/rust/blob/614f273e9388ddd7804d5cbc80b8865068a3744e/src/librustc_resolve/macros.rs#L456 Co-authored-by: Edwin Cheng <[email protected]>
| * | | | Test whether it is bang macro properlyEdwin Cheng2020-05-021-0/+4
| | |/ / | |/| |
* | | | Add missing members generates indented blocksAleksey Kladov2020-05-021-8/+0
| | | |
* | | | Cleanup inline testsAleksey Kladov2020-05-028-30/+59
| | | |
* | | | Update test dataAleksey Kladov2020-05-02178-10580/+10223
| | | |
* | | | Introduce EffectExprAleksey Kladov2020-05-027-76/+73
| | | |
* | | | Revert "Merge #4233"Aleksey Kladov2020-05-023-26/+42
| |_|/ |/| | | | | | | | | | | This reverts commit a5f2b16366f027ad60c58266a66eb7fbdcbda9f9, reversing changes made to c96b2180c1c4206a0a98c280b4d30897eb116336.
| | |
| \ \
*-. \ \ Merge #4220 #4240bors[bot]2020-05-012-17/+24
|\ \ \ \ | | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4220: Introduce LowerCtx r=matklad a=edwin0cheng This PR introduces `LowerCtx` for path lowering. After this PR, there are only 2 places remains for using deprecated `Path::from_ast`, which is related to `AstTransform` I am not familiar. I would like to change these in another PR by others ;) related disscusiion: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Path.3A.3Afrom_src And also fixed part of https://github.com/rust-analyzer/rust-analyzer/issues/4176#issuecomment-620672930 4240: Bump deps r=matklad a=lnicola Co-authored-by: Edwin Cheng <[email protected]> Co-authored-by: LaurenÈ›iu Nicola <[email protected]>
| | * | Bump depsLaurențiu Nicola2020-05-012-17/+24
| |/ /
* | | Merge #4246bors[bot]2020-05-018-74/+177
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4246: Validate uses of self and super r=matklad a=djrenren This change follows on the validation of the `crate` keyword in paths. It verifies the following things: `super`: - May only be preceded by other `super` segments - If in a `UseItem` then all semantically preceding paths also consist only of `super` `self` - May only be the start of a path Just a note, a couple times while working on this I found myself really wanting a Visitor of some sort so that I could traverse descendants while skipping sub-trees that are unimportant. Iterators don't really work for this, so as you can see I reached for recursion. Considering paths are generally small a fancy debounced visitor probably isn't important but figured I'd say something in case we had something like this lying around and I wasn't using it. Co-authored-by: John Renner <[email protected]>
| * | | Validate uses of self and superJohn Renner2020-05-018-74/+177
| | | |
* | | | Fix pub(self) visibility?Diana2020-05-011-1/+1
| |/ / |/| | | | | | | | Clippy complained about it and it seems wrong
* | | Introduce BlockModifierAleksey Kladov2020-04-302-2/+19
| | |
* | | Remove dead code, which elaborately pretends to be aliveAleksey Kladov2020-04-302-40/+7
|/ /
* | Fix a bunch of false-positives in join-linesAleksey Kladov2020-04-302-1/+5
| |
* | Merge #4227bors[bot]2020-04-305-80/+115
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-305-80/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Specifically, things like: use foo::{crate::bar}; Are now being caught, when before we only caught: use foo::{crate};
* | | Special-case try macro_rulesEdwin Cheng2020-04-302-0/+28
|/ /
* | Special-case try macro to better support 2015 editionAleksey Kladov2020-04-302-0/+36
| |