aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_syntax/src/ast/generated/nodes.rs
Commit message (Collapse)AuthorAgeFilesLines
* MinorAleksey Kladov2020-07-311-68/+62
|
* Rename LambdaExpr -> ClosureExprAleksey Kladov2020-07-311-21/+14
|
* Work on expressions grammarAleksey Kladov2020-07-311-659/+669
|
* Item is a StmtAleksey Kladov2020-07-311-2/+4
|
* Handwrite StmtAleksey Kladov2020-07-311-22/+0
|
* Move Stmt GrammarAleksey Kladov2020-07-311-84/+85
|
* Finalize TypeBound grammarAleksey Kladov2020-07-311-27/+27
|
* "Finalize" Types grammarAleksey Kladov2020-07-311-1/+3
| | | | | | | Note that `for` type is rust-analyzer's own invention. Both the reference and syn allow `for` only for fnptr types, and we allow them everywhere. This needs to be checked with respect to type bounds grammar...
* Reame PlaceholderType -> InferTypeAleksey Kladov2020-07-311-11/+11
|
* Rename TypeRef -> TypeAleksey Kladov2020-07-311-127/+127
| | | | | | | | | | The TypeRef name comes from IntelliJ days, where you often have both type *syntax* as well as *semantical* representation of types in scope. And naming both Type is confusing. In rust-analyzer however, we use ast types as `ast::Type`, and have many more semantic counterparts to ast types, so avoiding name clash here is just confusing.
* Use ty to access most TypeRefsAleksey Kladov2020-07-301-10/+10
|
* Remove TypeAscriptionOwnerAleksey Kladov2020-07-301-7/+7
|
* simplifyAleksey Kladov2020-07-301-18/+18
|
* Finalize attribute grammarAleksey Kladov2020-07-301-39/+2
|
* Dead codeAleksey Kladov2020-07-301-102/+76
|
* Introduce GenericParamAleksey Kladov2020-07-301-85/+128
|
* Finaize item grammarAleksey Kladov2020-07-301-64/+71
|
* Finalize impl GrammarAleksey Kladov2020-07-301-15/+16
|
* Finalize Trait grammarAleksey Kladov2020-07-301-16/+16
|
* Finalize const&static grammarAleksey Kladov2020-07-301-42/+43
|
* Rename EnumVariant -> VariantAleksey Kladov2020-07-301-15/+15
|
* Rename EnumDef -> EnumAleksey Kladov2020-07-301-21/+21
|
* Rename StructDef -> StructAleksey Kladov2020-07-301-21/+21
|
* Finalize union grammarAleksey Kladov2020-07-301-21/+21
|
* Finalize structs grammarAleksey Kladov2020-07-301-1/+0
|
* Rename FieldDef -> FieldAleksey Kladov2020-07-301-50/+46
|
* Rename RecordLit -> RecordExprAleksey Kladov2020-07-301-24/+26
|
* Rename TypeParamList -> GenericParamListAleksey Kladov2020-07-301-15/+15
|
* Rename TypeAliasDef -> TypeAliasAleksey Kladov2020-07-301-47/+45
|
* Rename FnDef -> FnAleksey Kladov2020-07-301-206/+209
|
* Rename UseItem -> UseAleksey Kladov2020-07-301-14/+15
|
* Add comma list to use treeAleksey Kladov2020-07-301-77/+78
|
* Finish extern crates grammarAleksey Kladov2020-07-301-62/+62
|
* Rename RenameAleksey Kladov2020-07-301-8/+8
|
* Finish Module grammarAleksey Kladov2020-07-301-0/+1
|
* Split ItemList & AssocItemListAleksey Kladov2020-07-301-21/+50
|
* Finish SourceFile grammarAleksey Kladov2020-07-291-1/+3
|
* Rename ModuleItem -> ItemAleksey Kladov2020-07-291-384/+384
|
* Rename NomialDef -> AdtDefAleksey Kladov2020-07-291-19/+19
|
* Switch to ungrammar from ast_srcAleksey Kladov2020-07-291-2204/+806
| | | | | | | | | | | | | | | | | | The primary advantage of ungrammar is that it (eventually) allows one to describe concrete syntax tree structure -- with alternatives and specific sequence of tokens & nodes. That should be re-usable for: * generate `make` calls * Rust reference * Hypothetical parser's evented API We loose doc comments for the time being unfortunately. I don't think we should add support for doc comments to ungrammar -- they'll make grammar file hard to read. We might supply docs as out-of band info, or maybe just via a reference, but we'll think about that once things are no longer in flux
* Dead codeAleksey Kladov2020-07-291-41/+0
|
* Remove dead codeAleksey Kladov2020-07-291-3/+1
|
* Remove dead codeAleksey Kladov2020-07-291-46/+0
|
* Apply codegen with idiomatic lifetimesVeetaha2020-06-111-137/+137
|
* Separating parsing of `for` in predicates and typesMatthew Jasper2020-06-101-0/+2
|
* correctly infer labelled breaksrobojumper2020-05-311-0/+1
|
* Support raw_ref_op's raw reference operatorrobojumper2020-05-281-0/+3
|
* Remove an equals sign from `ConstArg` (this probably pertains only to ↵veetaha2020-05-121-1/+0
| | | | | | ConstParam) (As per matklad)
* Convert TODO to a Note(matklad)veetaha2020-05-121-0/+1
|
* Convert to TODOs to FIXMEs as per matkladveetaha2020-05-121-4/+2
|