aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir_ty/src/tests/traits.rs
Commit message (Collapse)AuthorAgeFilesLines
* Test for non-working proc macro server assoc typesFlorian Diebold2020-04-161-0/+68
|
* Switch Chalk to recursive solverFlorian Diebold2020-04-161-29/+21
| | | | + various fixes related to that.
*-. Merge #3966 #3968bors[bot]2020-04-151-0/+27
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+27
| |/ | | | | | | | | | | | | | | | | | | | | | | 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-151-1/+72
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| | * Handle `Self::Type` in trait definitions when referring to own associated typeFlorian Diebold2020-04-131-1/+25
| |/ |/| | | | | It was implemented for other generic parameters for the trait, but not for `Self`.
| * Implement inline associated type boundsFlorian Diebold2020-04-131-0/+47
|/ | | | | | | 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 :)
* Fix Chalk panicFlorian Diebold2020-04-061-0/+25
| | | | | Fixes #3865. Basically I forgot to shift 'back' when we got `dyn Trait`s back from Chalk, so after going through Chalk a few times, the panic happened.
* Hide unit fn return typesLaurențiu Nicola2020-04-051-6/+6
|
* Resolve `Self::AssocTy` in implsFlorian Diebold2020-03-061-0/+41
| | | | | | | | | | To do this we need to carry around the original resolution a bit, because `Self` gets resolved to the actual type immediately, but you're not allowed to write the equivalent type in a projection. (I tried just comparing the projection base type with the impl self type, but that seemed too dirty.) This is basically how rustc does it as well. Fixes #3249.
* Do autoderef for indexingFlorian Diebold2020-02-291-0/+28
|
* Normalize associated types in types coming from ChalkFlorian Diebold2020-02-211-0/+42
| | | | Fixes #3232.
* Make Self implement the trait inside trait default methodsFlorian Diebold2020-02-141-0/+48
|
* Add two more testsFlorian Diebold2020-02-071-0/+51
|
* Don't print implicit type args from impl TraitFlorian Diebold2020-02-071-11/+11
|
* Deal better with implicit type parameters and argument listsFlorian Diebold2020-02-071-0/+108
|
* Clean up RPIT a bitFlorian Diebold2020-02-071-13/+11
|
* Fix APIT some moreFlorian Diebold2020-02-071-23/+28
|
* Change Ty::Param to contain param IDFlorian Diebold2020-02-071-2/+1
|
* WIP use params for APITFlorian Diebold2020-02-071-0/+53
|
* Fix assoc type selectionFlorian Diebold2020-02-071-3/+3
|
* Fix enum constructorsFlorian Diebold2020-02-071-1/+1
|
* Fix printing of function typesFlorian Diebold2020-02-071-16/+16
|
* wip implement lowering modeFlorian Diebold2020-02-071-20/+8
|
* Standard formatting for array typesAleksey Kladov2020-01-281-1/+1
|
* Ignore failing impl Trait testsFlorian Diebold2020-01-271-0/+2
|
* Resolve traits in infer using lang item infrastructureEmil Lauridsen2019-12-291-0/+5
|
* Merge #2661bors[bot]2019-12-241-0/+57
|\ | | | | | | | | | | | | | | | | | | | | | | 2661: Implement infer await from async function r=flodiebold a=edwin0cheng This PR is my attempt for trying to add support for infer `.await` expression from an `async` function, by desugaring its return type to `Impl Future<Output=RetType>`. Note that I don't know it is supposed to desugaring it in that phase, if it is not suitable in current design, just feel free to reject it :) r=@flodiebold Co-authored-by: Edwin Cheng <[email protected]>
| * Implement infer await from async funcEdwin Cheng2019-12-241-0/+57
| |
* | Filter out error predicates in type bounds as wellFlorian Diebold2019-12-221-0/+17
|/
* Coerce closures to fn pointersFlorian Diebold2019-12-201-5/+5
| | | | E.g. `let x: fn(A) -> B = |x| { y };`
* Add std::ops::Index support for inferingEdwin Cheng2019-12-191-0/+32
|
* Add test markFlorian Diebold2019-12-151-2/+6
|
* Handle impl Trait more correctlyFlorian Diebold2019-12-151-0/+31
| | | | | | | When calling a function, argument-position impl Trait is transparent; same for return-position impl Trait when inside the function. So in these cases, we need to represent that type not by `Ty::Opaque`, but by a type variable that can be unified with whatever flows into there.
* Add test for unifying impl TraitFlorian Diebold2019-12-151-1/+27
|
* Correctly infer - and ! using std::ops::{Neg,Not}Emil Lauridsen2019-12-131-0/+64
|
* Split up ty tests a bitFlorian Diebold2019-12-031-0/+1424