aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_syntax/src/grammar.ron
Commit message (Collapse)AuthorAgeFilesLines
...
* rename POS_FIELD -> POS_FIELD_DEFAleksey Kladov2019-01-251-4/+4
| | | | to match NAMED_FIELD_DEF
* Add docs to struct fieldsJeremy A. Kolb2019-01-251-1/+1
|
* Merge #630bors[bot]2019-01-251-21/+30
|\ | | | | | | | | | | | | | | | | | | | | | | 630: Fill in DocumentSymbol::detail r=matklad a=hban Closes: #516 I just pulled type text from the syntax node and "formatted" is bit. VS Code can't really handle multi-line symbol detail (it's will crop it when rendering), so that formatting will just collapse all white-space to singe space. It isn't pretty, but maybe there's a better way. Issue also mentions "need to be done for `NavigationTarget` to `SymbolInformation`", but `SymbolInformation` doesn't have detail field on it? Co-authored-by: Hrvoje Ban <[email protected]>
| * Fill in DocumentSymbol::detailHrvoje Ban2019-01-241-21/+30
| |
* | Migrate trait & type to new idsAleksey Kladov2019-01-241-2/+2
|/
* Make EnumVariant a DocCommentsOwnerJeremy A. Kolb2019-01-231-1/+1
|
* Add AST/HIR for type args in path segmentsFlorian Diebold2019-01-191-1/+9
|
* Change parsing of struct field patternsMarcus Klaas de Vries2019-01-191-1/+6
|
* Move parsing of field pattern lists to the parser (where it belongs)Marcus Klaas de Vries2019-01-191-1/+6
|
* Add initial (flawed) implementation of binding annotationsMarcus Klaas de Vries2019-01-191-1/+4
|
* Create struct patterns up to the hir levelMarcus Klaas de Vries2019-01-191-3/+2
|
* Add additional pattern variantsMarcus Klaas de Vries2019-01-191-2/+2
|
* Update ARRAY_EXPR grammarHirokazu Hata2019-01-161-1/+3
|
* Fix type inference for raw (byte) stringsMarcus Klaas de Vries2019-01-141-0/+4
|
* Fixup testsMarcus Klaas de Vries2019-01-141-4/+7
|
* Start moving literal interpretation to the AST (WIP)Marcus Klaas de Vries2019-01-141-2/+16
|
* Update TUPLE_EXPR grammarHirokazu Hata2019-01-131-1/+3
|
* support ref-patternsAleksey Kladov2019-01-131-1/+1
|
* itroduce trait for ast tokensAleksey Kladov2019-01-081-7/+7
|
* Add remaining binary operations to ASTMarcus Klaas de Vries2019-01-071-0/+1
|
* Make FnScopes use hir::ExprFlorian Diebold2019-01-051-6/+4
| | | | | | This was a bit complicated. I've added a wrapper type for now that does the LocalSyntaxPtr <-> ExprId translation; we might want to get rid of that or give it a nicer interface.
* Add HIR Expr machineryFlorian Diebold2019-01-051-2/+2
|
* Type the self parameterFlorian Diebold2019-01-041-1/+2
|
* Add HIR for impl blocksFlorian Diebold2019-01-041-1/+5
| | | | | | | | | Since we need to be able to go from def to containing impl block, as well as the other direction, and to find all impls for a certain type, a design similar to the one for modules, where we collect all impls for the whole crate and keep them in an arena, seemed fitting. The ImplBlock type, which provides the public interface, then consists only of an Arc to the arena containing all impls, and the index into it.
* Rename ImplItem to ImplBlockFlorian Diebold2019-01-041-3/+3
| | | | | rustc uses the name ImplItem for items in impls, not the impl {} block itself, which could lead to confusion.
* visibility ownerAleksey Kladov2019-01-031-4/+11
|
* super simplistic macro expansionAleksey Kladov2018-12-281-1/+1
|
* add macro-call nodeAleksey Kladov2018-12-281-0/+1
|
* Add a hir::TypeRef as an intermediate between ast::TypeRef and ty::TyFlorian Diebold2018-12-251-5/+5
|
* Implement reference / pointer typesFlorian Diebold2018-12-251-3/+3
| | | | | - parse them - infer types of & and * expressions
* Implement basic completion for fieldsFlorian Diebold2018-12-251-1/+1
|
* Type field accessesFlorian Diebold2018-12-251-1/+1
|
* Add AST definitions for struct/variant fields etc.Florian Diebold2018-12-251-5/+7
| | | | Fixes #117
* Infer result of struct literals, and recurse into their child expressionsFlorian Diebold2018-12-251-3/+3
|
* Resolve paths to defs (functions currently) during type inferenceFlorian Diebold2018-12-231-1/+1
|
* Make let statements kind of workFlorian Diebold2018-12-231-0/+1
|
* Parse integer / float typesFlorian Diebold2018-12-231-1/+1
|
* Add beginnings of type infrastructureFlorian Diebold2018-12-231-7/+7
|
* Clarify and correct comment about multi_byte_tokensDJMcNab2018-12-081-2/+2
|
* Validate byte string literalsAdolfo Ochagavía2018-11-111-0/+1
|
* Add validator for byteAdolfo Ochagavía2018-11-111-0/+1
|
* Validate string literalsAdolfo Ochagavía2018-11-091-0/+1
|
* rename ROOT -> SOURCE_FILEAleksey Kladov2018-11-071-2/+2
|
* Add some more DocCommentsOwnerJeremy A. Kolb2018-11-071-2/+7
|
* Add character literal parsing and validationAdolfo Ochagavía2018-11-041-0/+1
|
* Remove DOC_COMMENTJeremy A. Kolb2018-10-311-1/+0
| | | | Closes #166
* `ast::DocCommentsOwner` which represents a documentation comment ownerJeremy A. Kolb2018-10-311-0/+1
|
* Complete crate:: pathsAleksey Kladov2018-10-241-1/+2
|
* rename gen-kinds to gen-syntaxAleksey Kladov2018-10-161-1/+1
|
* Merge #127bors[bot]2018-10-151-0/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 127: Improve folding r=matklad a=aochagavia I was messing around with adding support for multiline comments in folding and ended up changing a bunch of other things. First of all, I am not convinced of folding groups of successive items. For instance, I don't see why it is worthwhile to be able to fold something like the following: ```rust use foo; use bar; ``` Furthermore, this causes problems if you want to fold a multiline import: ```rust use foo::{ quux }; use bar; ``` The problem is that now there are two possible folds at the same position: we could fold the first use or we could fold the import group. IMO, the only place where folding groups makes sense is when folding comments. Therefore I have **removed folding import groups in favor of folding multiline imports**. Regarding folding comments, I made it a bit more robust by requiring that comments can only be folded if they have the same flavor. So if you have a bunch of `//` comments followed by `//!` comments, you will get two separate fold groups instead of a single one. Finally, I rewrote the API in such a way that it should be trivial to add new folds. You only need to: * Create a new FoldKind * Add it to the `fold_kind` function that converts from `SyntaxKind` to `FoldKind` Fixes #113 Co-authored-by: Adolfo Ochagavía <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-02 17:12:24 +0000