aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_syntax
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
| |
* | Merge #4178bors[bot]2020-04-304-0/+120
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4178: Validate the location of `crate` in paths r=matklad a=djrenren **This solution does not fully handle `use` statements. See below** This pull requests implements simple validation of usages of the `crate` keyword in `Path`s. Specifically it validates that: - If a `PathSegment` is starts with the `crate` keyword, it is also the first segment of the `Path` - All other usages of `crate` in `Path`s are considered errors. This aligns with `rustc`'s rules. Unlike rustc this implementation does not issue a special error message in the case of `::crate` but it does catch the error. Furthermore, this change does not cover all error cases. Specifically the following is not caught: ```rust use foo::{crate} ``` This is because this check is context sensitive. From an AST perspective, `crate` is the root of the `Path`. Only by inspecting the full `UseItem` do we see that it is not in fact the root. This problem becomes worse because `UseTree`s are allowed to be arbitrarily nested: ```rust use {crate, {{crate, foo::{crate}}} ``` So this is a hard problem to solve without essentially a breadth-first search. In a traditional compiler, I'd say this error is most easily found during the AST -> HIR conversion pass but within rust-analyzer I'm not sure where it belongs. Under the implementation in this PR, such errors are ignored so we're *more correct* just not *entirely correct*. Co-authored-by: John Renner <[email protected]>
| * | Validate the location of `crate` in pathsJohn Renner2020-04-294-0/+120
| |/
* | More principled approach for finding From traitAleksey Kladov2020-04-291-2/+1
| |
* | Fix comment prefix method for four slash commentsadamrk2020-04-281-10/+6
| |
* | Treat comments beginning with four slashes as regular line commentsadamrk2020-04-282-0/+16
|/
* Merge #4134bors[bot]2020-04-251-0/+3
|\ | | | | | | | | | | | | | | | | | | 4134: Special case for empty comments in doc comment kind r=matklad a=edwin0cheng Part of #4103 Fix `ui/empty/empty-comment.rs macros` Co-authored-by: Edwin Cheng <[email protected]>
| * Special case for empty commentsEdwin Cheng2020-04-251-0/+3
| |
* | text-size 1.0.0Aleksey Kladov2020-04-251-1/+1
| |
* | Switch to TryFromAleksey Kladov2020-04-255-24/+31
| |
* | Convert tests to text-sizeAleksey Kladov2020-04-25335-22878/+22878
| |
* | Convert code to text-sizeAleksey Kladov2020-04-2514-66/+60
| |
| |
| \
*-. \ Merge #3998 #4006bors[bot]2020-04-242-1/+369
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3998: Make add_function generate functions in other modules via qualified path r=matklad a=TimoFreiberg Additional feature for #3639 - [x] Add tests for paths with more segments - [x] Make generating the function in another file work - [x] Add `pub` or `pub(crate)` to the generated function if it's generated in a different module - [x] Make the assist jump to the edited file - [x] Enable file support in the `check_assist` helper 4006: Syntax highlighting for format strings r=matklad a=ltentrup I have an implementation for syntax highlighting for format string modifiers `{}`. The first commit refactors the changes in #3826 into a separate struct. The second commit implements the highlighting: first we check in a macro call whether the macro is a format macro from `std`. In this case, we remember the format string node. If we encounter this node during syntax highlighting, we check for the format modifiers `{}` using regular expressions. There are a few places which I am not quite sure: - Is the way I extract the macro names correct? - Is the `HighlightTag::Attribute` suitable for highlighting the `{}`? Let me know what you think, any feedback is welcome! Co-authored-by: Timo Freiberg <[email protected]> Co-authored-by: Leander Tentrup <[email protected]> Co-authored-by: Leander Tentrup <[email protected]>
| | * Adapt format specifier highlighting to support escaped squences and unicode ↵Leander Tentrup2020-04-221-122/+158
| | | | | | | | | | | | identifiers
| | * Apply suggestions from code reviewLeander Tentrup2020-04-221-30/+29
| | | | | | | | | | | | Co-Authored-By: bjorn3 <[email protected]>
| | * Implement syntax highlighting for format stringsLeander Tentrup2020-04-201-0/+324
| | | | | | | | | | | | | | | | | | | | | Detailed changes: 1) Implement a lexer for string literals that divides the string in format specifier `{}` including the format specifier modifier. 2) Adapt syntax highlighting to add ranges for the detected sequences. 3) Add a test case for the format string syntax highlighting.
| * | Add `pub(crate)` to functions generated in other moduleTimo Freiberg2020-04-211-0/+4
| | |
| * | Make add_function generate functions in other modules via qualified pathTimo Freiberg2020-04-211-1/+6
| | |
* | | minorAleksey Kladov2020-04-231-4/+0
| | |
* | | Fully get rid of SyntaxNodePtr::rangeAleksey Kladov2020-04-231-3/+3
|/ /
* | Merge #4038bors[bot]2020-04-211-1462/+1462
|\ \ | | | | | | | | | | | | | | | | | | | | | 4038: Group generated ast boilerplate apart from the interesting part r=matklad a=Veetaha Boilerplate `AstNode` and `From` impls are moved to the end further from the interesting part in `generated.rs` Co-authored-by: veetaha <[email protected]>
| * | Group generated ast boilerplate apart from the interesting partveetaha2020-04-181-1462/+1462
| |/
* / Fix panic in split_imports assistAleksey Kladov2020-04-202-3/+11
|/ | | | | | | | | | | | | | | The fix is admittedly quit literally just papering over. Long-term, I see two more principled approaches: * we switch to a fully tree-based impl, without parse . to_string step; with this approach, there shouldn't be any panics. The results might be nonsensical, but so was the original input. * we preserve the invariant that re-parsing constructed node is an identity, and make all the `make_xxx` method return an `Option`. closes #4044
* Don't expose SyntaxNodePtr impl detailsAleksey Kladov2020-04-162-7/+3
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-09 03:24:25 +0000