aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_syntax/src/ast
Commit message (Collapse)AuthorAgeFilesLines
...
* | | Merge branch 'master' of github.com:rust-analyzer/rust-analyzerBenjamin Coenen2020-05-014-52/+35
|\| |
| * | Introduce BlockModifierAleksey Kladov2020-04-301-1/+16
| | |
| * | 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 #4178bors[bot]2020-04-301-0/+1
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-291-0/+1
| | |
| * | 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-281-0/+1
| |/
* / Add unwrap block assist #4156Benjamin Coenen2020-04-291-1/+1
|/ | | | Signed-off-by: Benjamin Coenen <[email protected]>
* 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
| |
* | Switch to TryFromAleksey Kladov2020-04-251-8/+6
| |
* | Convert code to text-sizeAleksey Kladov2020-04-251-18/+14
| |
| |
| \
*-. \ 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
|/ /
* | 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-201-1/+5
|/ | | | | | | | | | | | | | | 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
* Align grammar for record patterns and literalsAleksey Kladov2020-04-112-1/+31
| | | | | | The grammar now looks like this [name_ref :] pat
* Remove dead codeAleksey Kladov2020-04-111-2/+0
|
* Make records grammar more orthogonalAleksey Kladov2020-04-111-0/+32
| | | | | | | | | | | | We used name [: expr] grammar before, now it is [name :] expr which makes things simpler
* Change missing impl assist to use todo!() instead of unimplemented()Chris Hopman2020-04-101-0/+3
| | | | | | | | | | | | todo!() "Indicates unfinished code" (https://doc.rust-lang.org/std/macro.todo.html) Rust documentation provides further clarification: > The difference between unimplemented! and todo! is that while todo! > conveys an intent of implementing the functionality later and the > message is "not yet implemented", unimplemented! makes no such claims. todo!() seems more appropriate for assists that insert missing impls.
* SimplifyAleksey Kladov2020-04-102-19/+2
|
* Rename some tokensAleksey Kladov2020-04-101-1/+1
|
* Better readabilityAleksey Kladov2020-04-102-0/+142
|
* Remove dead codeAleksey Kladov2020-04-103-194/+186
|
* Generate only minimal set of ineresting tokensAleksey Kladov2020-04-104-1301/+22
|
* Scale token generation backAleksey Kladov2020-04-103-306/+69
|
* Convert more tokensAleksey Kladov2020-04-102-217/+13
|
* Other delimitersAleksey Kladov2020-04-101-32/+32
|
* Curley tokensAleksey Kladov2020-04-104-114/+32
|
* Start replacing tokensAleksey Kladov2020-04-101-34/+12
|
* Semicolon tokenAleksey Kladov2020-04-102-13/+35
|
* More readable ast_src for keywordsAleksey Kladov2020-04-101-69/+77
|
* Simpler acessors for keywordsAleksey Kladov2020-04-094-998/+82
|
* use uniform accessorAleksey Kladov2020-04-091-4/+0
|
* use stdxAleksey Kladov2020-04-091-3/+3
|
* Drop needless traitAleksey Kladov2020-04-092-10/+0
|
* Remove code duplicationAleksey Kladov2020-04-094-35/+32
|
* Be consistent about token accesorsAleksey Kladov2020-04-093-98/+13
|
* Add _token suffix to token accessorsAleksey Kladov2020-04-093-204/+200
| | | | | I think this makes is more clear which things are : AstNode and which are : AstToken
* SimplifyAleksey Kladov2020-04-091-26/+13
|
* Put displays at the endAleksey Kladov2020-04-091-690/+690
|
* More compactAleksey Kladov2020-04-092-1428/+238
|
* More compact generated codeAleksey Kladov2020-04-093-2184/+730
|