| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| | |
instead of ast::Path
|
| |
| |
| |
| | |
reusable
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1193: Add a test for #1178 case r=edwin0cheng a=edwin0cheng
A little PR to add a test case for #1178
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | |
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1184: Start structured editing API r=matklad a=matklad
I think I finally understand how to provide nice, mutable structured editing API on top of red-green trees.
The problem I am trying to solve is that any modification to a particular `SyntaxNode` returns an independent new file. So, if you are editing a struct literal, and add a field, you get back a SourceFile, and you have to find the struct literal inside it yourself! This happens because our trees are immutable, but have parent pointers.
The main idea here is to introduce `AstEditor<T>` type, which abstracts away that API. So, you create an `AstEditor` for node you want to edit and call various `&mut` taking methods on it. Internally, `AstEditor` stores both the original node and the current node. All edits are applied to the current node, which is replaced by the corresponding node in the new file. In the end, `AstEditor` computes a text edit between old and new nodes.
Note that this also should sole a problem when you create an anchor pointing to a subnode and mutate the parent node, invalidating anchor. Because mutation needs `&mut`, all anchors must be killed before modification.
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Currently, this is more code, and we also loose auto-indenting of
bodies, but, long-term, this is the right approach
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|/| |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
| |
This prevents any `impl<T> Trait for T where ...` from being treated as a
blanket impl while we don't handle where clauses yet.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1175: Fix bugs and add error log about macro expansion r=matklad a=edwin0cheng
This PR fixed / add following things:
* Add a fused count which stop recursion of macro expansion in name resolution.
* Add some logs when macro expansion fails
* Add `$crate` meta variable support in mbe, which create a `$crate` ident token in token tree.
* Fixed matching a `$REPEAT` pattern inside a subtree, e.g. `(fn $name:ident {$($i:ident)*} ) => {...}`
* Remove composite-able punct token in syntax node to token conversion.
Co-authored-by: Edwin Cheng <[email protected]>
|
| | |
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1154: Initial support for lang items (and str completion) r=flodiebold a=marcogroppo
This PR adds partial support for lang items.
For now, the only supported lang items are the ones that target an impl block.
Lang items are now resolved during type inference - this means that `str` completion now works.
Fixes #1139.
(thanks Florian Diebold for the help!)
Co-authored-by: Marco Groppo <[email protected]>
|
| | |
|
| |
| |
| |
| | |
Renamed Impl to ImplBlock.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1148: Add token_tree_to_xxx functions r=matklad a=edwin0cheng
<del>As discus in PR #1147 , this PR added a `mbe::MacroKind` .
Currently only 2 kind of macro are supported, `SourceFile` and `Block`.</del>
Added following functions for `tt::TokenTree` and `ast::Node` conversion:
* token_tree_to_expr
* token_tree_to_pat
* token_tree_to_ty
* token_tree_to_macro_stmts
* token_tree_to_macro_items
And added two new syntax kind:
* MACRO_ITEMS
* MACRO_STMTS
Co-authored-by: Edwin Cheng <[email protected]>
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1160: better formatting when adding trait members r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |
| |
| |
| |
| |
| | |
* it's conventional not to use one-liners
* new placement is more predictable, b/c it does not depend on
header's length
|