aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_syntax
Commit message (Collapse)AuthorAgeFilesLines
...
| * | 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
|
* Align grammar for record patterns and literalsAleksey Kladov2020-04-118-36/+74
| | | | | | The grammar now looks like this [name_ref :] pat
* Remove dead codeAleksey Kladov2020-04-112-2/+5
|
* Make records grammar more orthogonalAleksey Kladov2020-04-114-4/+94
| | | | | | | | | | | | We used name [: expr] grammar before, now it is [name :] expr which makes things simpler
* Merge pull request #3935 from cjhopman/todoAleksey Kladov2020-04-111-0/+3
|\ | | | | Change missing impl assist to use todo!() instead of unimplemented()
| * 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.
* | Forward compatAleksey Kladov2020-04-101-9/+8
|/
* SimplifyAleksey Kladov2020-04-102-19/+2
|
* Rename some tokensAleksey Kladov2020-04-10199-1043/+1042
|
* Better readabilityAleksey Kladov2020-04-102-0/+142
|
* Remove dead codeAleksey Kladov2020-04-104-195/+187
|
* Generate only minimal set of ineresting tokensAleksey Kladov2020-04-105-1306/+23
|
* 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-095-999/+87
|
* 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-095-60/+49
|
* Be consistent about token accesorsAleksey Kladov2020-04-093-98/+13
|
* Add _token suffix to token accessorsAleksey Kladov2020-04-094-205/+201
| | | | | 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
|
* Move the rest of the tokens to generated/tokensAleksey Kladov2020-04-092-653/+653
|
* Move generated tokens to a separate fileAleksey Kladov2020-04-093-3055/+3060
|
* Start ast/generated/tokensAleksey Kladov2020-04-092-0/+2
|
* Prepare for spliting generated into tokens and nodesAleksey Kladov2020-04-093-9625/+9628
|
* Remove allocations from LCAAleksey Kladov2020-04-091-3/+13
| | | | | I haven't actually profiled this, but not allocating a hash map (or anything, really) seems like a good idea
* Parse correctly fn f<T>() where T: Fn() -> u8 + Send {}Luca Barbieri2020-04-092-0/+62
| | | | | We used to parse it as T: Fn() -> (u8 + Send), which is different from the rustc behavior of T: (Fn() -> u8) + Send
* Scale back to only two traitsAleksey Kladov2020-04-094-187/+1959
|
* Provide more complete AST accessors to support usage in rustcLuca Barbieri2020-04-095-104/+108
|
* Scale back the traitsAleksey Kladov2020-04-092-105/+3033
|
* Add AstElement trait, generate tokens, support tokens in enumsLuca Barbieri2020-04-082-65/+111
| | | | | | | | | - Adds a new AstElement trait that is implemented by all generated node, token and enum structs - Overhauls the code generators to code-generate all tokens, and also enhances enums to support including tokens, node, and nested enums
* Fix warnings emitted when compiling as part of rustcLuca Barbieri2020-04-081-1/+1
|
* Merge pull request #3863 from Veetaha/feature/migrate-to-rastAleksey Kladov2020-04-07277-7/+7
|\ | | | | Migrate tests .txt -> .rast
| * Migrate tests .txt -> .rastveetaha2020-04-06277-7/+7
| | | | | | | | | | | | | | | | The sytax tree output files now use .rast extension (rust-analyzer syntax tree or rust abstract syntax tree (whatever)). This format has a editors/code/ra_syntax_tree.tmGrammar.json declaration that supplies nice syntax highlighting for .rast files.
* | Fix unnecessary braces warningsLaurențiu Nicola2020-04-061-6/+6
|/
* Remove rustc_lexer dependency in favour of rustc-ap-rustc_lexerest312020-04-061-1/+1
| | | | The latter is auto-published on a regular schedule (Right now weekly).
* Remove the second code-path for completing names in patternsAleksey Kladov2020-04-031-0/+3
|
* Macro patterns are not confused with expressions.Aleksey Kladov2020-04-032-11/+52
| | | | | | | | | | | We treat macro calls as expressions (there's appropriate Into impl), which causes problem if there's expresison and non-expression macro in the same node (like in the match arm). We fix this problem by nesting macor patterns into another node (the same way we nest path into PathExpr or PathPat). Ideally, we probably should add a similar nesting for macro expressions, but that needs some careful thinking about macros in blocks: `{ am_i_expression!() }`.
* Merge #3746bors[bot]2020-04-031-0/+25
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3746: Add create_function assist r=flodiebold a=TimoFreiberg The function part of #3639, creating methods will come later - [X] Function arguments - [X] Function call arguments - [x] Method call arguments - [x] Literal arguments - [x] Variable reference arguments - [X] Migrate to `ast::make` API Done, but there are some ugly spots. Issues to handle in another PR: - function reference arguments: Their type isn't printed properly right now. The "insert explicit type" assist has the same issue and this is probably a relatively rare usecase. - generating proper names for all kinds of argument expressions (if, loop, ...?) Without this, it's totally possible for the assist to generate invalid argument names. I think the assist it's already helpful enough to be shipped as it is, at least for me the main usecase involves passing in named references. Besides, the Rust tooling ecosystem is immature enough that some janky behaviour in a new assist probably won't scare anyone off. - select the generated placeholder body so it's a bit easier to overwrite it - create method (`self.foo<|>(..)` or `some_foo.foo<|>(..)`) instead of create_function. The main difference would be finding (or creating) the impl block and inserting the `self` argument correctly - more specific default arg names for literals. So far, every generated argument whose name can't be taken from the call site is called `arg` (with a number suffix if necessary). - creating functions in another module of the same crate. E.g. when typing `some_mod::foo<|>(...)` when in `lib.rs`, I'd want to have `foo` generated in `some_mod.rs` and jump there. Issues: the mod could exist in `some_mod.rs`, in `lib.rs` as `mod some_mod`, or inside another mod but be imported via `use other_mod::some_mod`. - refer to arguments of the generated function with a qualified path if the types aren't imported yet (alternative: run autoimport. i think starting with a qualified path is cleaner and there's already an assist to replace a qualified path with an import and an unqualified path) - add type arguments of the arguments to the generated function - Autocomplete functions with information from unresolved calls (see https://github.com/rust-analyzer/rust-analyzer/pull/3746#issuecomment-605281323) Issues: see https://github.com/rust-analyzer/rust-analyzer/pull/3746#issuecomment-605282542. The unresolved call could be anywhere. But just offering this autocompletion for unresolved calls in the same module would already be cool. Co-authored-by: Timo Freiberg <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-05 10:36:28 +0000