aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir_def
Commit message (Collapse)AuthorAgeFilesLines
* Correctly infer types in guard expressionsAleksey Kladov2020-04-181-0/+4
| | | | | | | The root cause was that we forgot to add bindings from the arm to the guard expression closes #3980
* find_path: Builtins are always in scopeFlorian Diebold2020-04-182-25/+50
| | | | Fixes #3977.
* Merge #4012bors[bot]2020-04-171-3/+10
|\ | | | | | | | | | | | | | | 4012: fix panic on ellipsis in pattern r=flodiebold a=JoshMcguigan fixes #3999 Co-authored-by: Josh Mcguigan <[email protected]>
| * fix panic on ellipsis in patternJosh Mcguigan2020-04-171-3/+10
| |
* | Simplify Diagnostic structureAleksey Kladov2020-04-172-7/+2
| | | | | | | | | | | | It's not entirely clear what subnode ranges should mean in the presence of macros, so let's leave them out for now. We are not using them heavily anyway.
* | Correctly highlight ranges of diagnostics from macrosAleksey Kladov2020-04-171-3/+3
| | | | | | | | closes #2799
* | Don't expose impl details of SyntaxPtrAleksey Kladov2020-04-174-5/+11
|/
*-. Merge #3966 #3968bors[bot]2020-04-151-4/+14
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3966: Add support for bounds on associated types in trait definitions r=matklad a=flodiebold E.g. ```rust trait Trait { type Item: SomeOtherTrait; } ``` Note that these don't simply desugar to where clauses; as I understand it, where clauses have to be proved by the *user* of the trait, but these bounds are proved by the *implementor*. (Also, where clauses on associated types are unstable.) (Another one from my recursive solver branch...) 3968: Remove format from syntax_bridge hot path r=matklad a=edwin0cheng Although only around 1% speed up by running: ``` Measure-Command {start-process .\target\release\rust-analyzer "analysis-stats -q ." -NoNewWindow -wait} ``` Co-authored-by: Florian Diebold <[email protected]> Co-authored-by: Edwin Cheng <[email protected]>
| * | Add support for bounds on associated types in trait definitionsFlorian Diebold2020-04-131-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | E.g. ``` trait Trait { type Item: SomeOtherTrait; } ``` Note that these don't simply desugar to where clauses; as I understand it, where clauses have to be proved by the *user* of the trait, but these bounds are proved by the *implementor*. (Also, where clauses on associated types are unstable.)
| | |
| \ \
*-. \ \ Merge #3964 #3965 #3967bors[bot]2020-04-154-11/+51
|\ \ \ \ | | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3964: Nicer Chalk debug logs r=matklad a=flodiebold I'm looking at a lot of Chalk debug logs at the moment, so here's a few changes to make them slightly nicer... 3965: Implement inline associated type bounds r=matklad a=flodiebold Like `Iterator<Item: SomeTrait>`. This is an unstable feature, but it's used in the standard library e.g. in the definition of Flatten, so we can't get away with not implementing it :) (This is cherry-picked from my recursive solver branch, where it works better, but I did manage to write a test that works with the current Chalk solver as well...) 3967: Handle `Self::Type` in trait definitions when referring to own associated type r=matklad a=flodiebold It was implemented for other generic parameters for the trait, but not for `Self`. (Last one off my recursive solver branch :smile: ) Co-authored-by: Florian Diebold <[email protected]>
| | * | Implement inline associated type boundsFlorian Diebold2020-04-134-11/+51
| |/ / | | | | | | | | | | | | | | | | | | Like `Iterator<Item: SomeTrait>`. This is an unstable feature, but it's used in the standard library e.g. in the definition of Flatten, so we can't get away with not implementing it :)
* | | insta 0.16kjeremy2020-04-141-1/+1
| | |
* | | handle tuple patterns with ellipsisJosh Mcguigan2020-04-132-8/+25
|/ /
* | Align grammar for record patterns and literalsAleksey Kladov2020-04-111-1/+1
| | | | | | | | | | | | The grammar now looks like this [name_ref :] pat
* | Merge #3925bors[bot]2020-04-111-1/+0
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 3925: Implement assist "Reorder field names" r=matklad a=geoffreycopin This PR implements the "Reorder record fields" assist as discussed in issue #3821 . Adding a `RecordFieldPat` variant to the `Pat` enum seemed like the easiest way to handle the `RecordPat` children as a single sequence of elements, maybe there is a better way ? Co-authored-by: Geoffrey Copin <[email protected]>
| * | Avoid adding a RecordFieldPat variant to the Pat enumGeoffrey Copin2020-04-111-2/+0
| | |
| * | Implement assist "Reorder field names"Geoffrey Copin2020-04-091-1/+2
| | |
* | | Remove dead codeAleksey Kladov2020-04-112-6/+5
| | |
* | | Make records grammar more orthogonalAleksey Kladov2020-04-113-32/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We used name [: expr] grammar before, now it is [name :] expr which makes things simpler
* | | Make incremental nameres test harderAleksey Kladov2020-04-111-0/+6
| | |
* | | Avoid cyclic queries in name resolution when processing enumsAleksey Kladov2020-04-113-15/+48
| | |
* | | Align namingAleksey Kladov2020-04-114-6/+5
| | |
* | | Remove code duplicationAleksey Kladov2020-04-112-5/+2
| | |
* | | Use Expander for cfg handling in structsAleksey Kladov2020-04-111-10/+10
| | |
* | | Use Expander for cfg handling in implsAleksey Kladov2020-04-111-13/+14
| | |
* | | Pull Expander upAleksey Kladov2020-04-113-11/+24
| | |
* | | SimplifyAleksey Kladov2020-04-112-8/+8
| |/ |/|
* | Forward compatAleksey Kladov2020-04-103-7/+7
| |
* | profile queriesAleksey Kladov2020-04-101-0/+5
| |
* | Semicolon tokenAleksey Kladov2020-04-101-1/+1
| |
* | add record pat missing field diagnosticJosh Mcguigan2020-04-102-28/+9
|/
* Simpler acessors for keywordsAleksey Kladov2020-04-093-10/+8
|
* use uniform accessorAleksey Kladov2020-04-091-1/+1
|
* Merge #3918bors[bot]2020-04-094-45/+82
|\ | | | | | | | | | | | | | | | | 3918: Add support for feature attributes in struct literal r=matklad a=bnjjj As promised here is the next PR to solve 2 different scenarios with feature flag on struct literal. close #3870 Co-authored-by: Benjamin Coenen <[email protected]>
| * feat: add support for feature attributes in struct literalBenjamin Coenen2020-04-095-5/+16
| |\ | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
| * | feat: add support for feature attributes in struct literalBenjamin Coenen2020-04-094-45/+82
| | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
* | | Be consistent about token accesorsAleksey Kladov2020-04-095-9/+12
| | |
* | | Add _token suffix to token accessorsAleksey Kladov2020-04-092-2/+2
| |/ |/| | | | | | | I think this makes is more clear which things are : AstNode and which are : AstToken
* | Scale back to only two traitsAleksey Kladov2020-04-091-1/+0
| |
* | Provide more complete AST accessors to support usage in rustcLuca Barbieri2020-04-095-5/+17
|/
* feat: add attributes support on struct fields and method #3870Benjamin Coenen2020-04-082-31/+24
| | | | Signed-off-by: Benjamin Coenen <[email protected]>
* Merge branch 'master' of github.com:rust-analyzer/rust-analyzerBenjamin Coenen2020-04-071-0/+5
|\
| * Check for eprintln on CIAleksey Kladov2020-04-061-0/+5
| |
* | feat: add attributes support on struct fields #3870Benjamin Coenen2020-04-072-4/+33
|/ | | | Signed-off-by: Benjamin Coenen <[email protected]>
* Fix inference of function pointer return typesLaurențiu Nicola2020-04-051-1/+5
|
* Macro patterns are not confused with expressions.Aleksey Kladov2020-04-031-2/+1
| | | | | | | | | | | 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!() }`.
* lower bool literal with the value from source code rather than default bool ↵Josh Mcguigan2020-04-011-1/+1
| | | | value
* lower literal patternsJosh Mcguigan2020-04-011-21/+33
|
* Nice string formattingAleksey Kladov2020-03-282-2/+5
|
* Merge #3727bors[bot]2020-03-261-4/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 3727: Introduce ra_proc_macro r=matklad a=edwin0cheng This PR implemented: 1. Reading dylib path of proc-macro crate from cargo check , similar to how `OUTDIR` is obtained. 2. Added a new crate `ra_proc_macro` and implement the foot-work for reading result from external proc-macro expander. 3. Added a struct `ProcMacroClient` , which will be responsible to the client side communication to the External process. Co-authored-by: Edwin Cheng <[email protected]>