Commit message (Collapse) | Author | Age | Files | Lines | ||
---|---|---|---|---|---|---|
... | ||||||
* | Implement const pat inference | Lukas Wirth | 2020-12-23 | 1 | -0/+30 | |
| | ||||||
* | Make macro def krate mandatory | Jonas Schievink | 2020-12-15 | 1 | -0/+6 | |
| | | | | Refactors builtin derive support to go through proper name resolution | |||||
* | Move to upstream `macro_rules!` model | Jonas Schievink | 2020-12-15 | 1 | -1/+0 | |
| | ||||||
* | Add regression test | Edwin Cheng | 2020-12-15 | 1 | -0/+24 | |
| | ||||||
* | Add test for #6852 | Florian Diebold | 2020-12-13 | 1 | -0/+37 | |
| | ||||||
* | Infer labeled blocks | Lukas Wirth | 2020-12-11 | 1 | -0/+56 | |
| | ||||||
* | Upgrade Chalk | Florian Diebold | 2020-12-07 | 1 | -0/+43 | |
| | | | | | | | Also make overflow depth and max type size configurable through env variables. This can be helpful at least for debugging. Fixes #6628. | |||||
* | Use correct, full substs for self type in impl | Florian Diebold | 2020-12-04 | 1 | -0/+19 | |
| | | | | | | | | Without arbitrary self types, the self type could never refer to the method type parameters, so this wasn't a problem; but with arbitrary self types, it can. This fixes the crash from #6668; but it doesn't make method resolution work for these methods. | |||||
* | Properly infer tuple struct patterns when encountering ellipsis | Lukas Wirth | 2020-11-24 | 1 | -0/+48 | |
| | ||||||
* | Properly infer tuple patterns when encountering ellipsis | Lukas Wirth | 2020-11-24 | 1 | -0/+47 | |
| | ||||||
* | binary operator overload type inference: add test mark | Roland Ruckerbauer | 2020-10-14 | 1 | -0/+3 | |
| | ||||||
* | Implement binary operator overloading type inference | Roland Ruckerbauer | 2020-10-13 | 1 | -0/+86 | |
| | ||||||
* | Use Ty::apply instead of simple and fix method resolution. | Charles Lew | 2020-09-16 | 1 | -3/+1 | |
| | ||||||
* | Add a test. | Charles Lew | 2020-09-16 | 1 | -0/+38 | |
| | ||||||
* | Merge #5971 | bors[bot] | 2020-09-13 | 2 | -18/+67 | |
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5971: Implement async blocks r=flodiebold a=oxalica Fix #4018 @flodiebold already gave a generic guide in the issue. Here's some concern about implementation detail: - Chalk doesn't support generator type yet. - Adding generator type as a brand new type (ctor) can be complex and need to *re-introduced* builtin impls. (Like how we implement closures before native closure support of chalk, which is already removed in #5401 ) - The output type of async block should be known after type inference of the whole body. - We cannot directly get the type from source like return-positon-impl-trait. But we still need to provide trait bounds when chalk asking for `opaque_ty_data`. - During the inference, the output type of async block can be temporary unknown and participate the later inference. `let a = async { None }; let _: i32 = a.await.unwrap();` So in this PR, the type of async blocks is inferred as an opaque type parameterized by the `Future::Output` type it should be, like what we do with closure type. And it really works now. Well, I still have some questions: - The bounds `AsyncBlockImplType<T>: Future<Output = T>` is currently generated in `opaque_ty_data`. I'm not sure if we should put this code here. - Type of async block is now rendered as `impl Future<Output = OutputType>`. Do we need to special display to hint that it's a async block? Note that closure type has its special format, instead of `impl Fn(..) -> ..` or function type. Co-authored-by: oxalica <[email protected]> | |||||
| * | Implement async blocks | oxalica | 2020-09-10 | 2 | -18/+67 | |
| | | ||||||
* | | Add box pattern test | Jonas Schievink | 2020-09-12 | 1 | -0/+25 | |
|/ | ||||||
* | Switch to expect_test from crates.io | Aleksey Kladov | 2020-08-21 | 8 | -8/+8 | |
| | ||||||
* | Rename ra_hir_ty -> hir_ty | Aleksey Kladov | 2020-08-13 | 9 | -0/+9980 | |