| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
- all the types that will be replaced by Chalk go to `types`
- `TypeWalk` impls go to `walk`
|
|
|
|
|
|
|
| |
Plus some more adaptations to Substitution.
Lots of `assert_ty_ref` that we should revisit when introducing
lifetime/const parameters.
|
|
|
|
|
|
| |
This in particular means storing a chalk_ir::Environment, not our
TraitEnvironment. This makes InEnvironment not usable for Type, where we
need to keep the full TraitEnvironment.
|
|
|
|
| |
In particular, use chalk_ir::CanonicalVarKinds.
|
|
|
|
|
| |
Still far too much binder skipping going on; I find it hard to imagine
this is all correct, but the tests pass.
|
|
|
|
|
| |
This introduces a bunch of new binders in lots of places, which we have
to be careful about, but we had to add them at some point.
|
|
|
|
| |
This includes starting to make use of Chalk's `Cast` trait.
|
|
|
|
|
| |
Chalk doesn't have it, and judging from the removed code, it wasn't
useful anyway.
|
| |
|
| |
|
| |
|
|
|
|
| |
example: let x: String = String::from("hello world").into();
|
| |
|
|
|
|
|
| |
Doesn't help as much as I hoped, but it helps a bit and I also did some
refactorings that were necessary anyway.
|
| |
|
|
|
|
|
|
|
|
| |
... like it will be in Chalk. We still keep `interned_mut` and
`into_inner` methods that will probably not exist with Chalk.
This worsens performance slightly (5ginstr inference on RA), but doesn't
include other simplifications we can do yet.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Currently `Ty` just wraps `TyKind`, but this allows us to change most
places to already use `intern` / `interned`.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Pulls in https://github.com/rust-lang/chalk/pull/682
|
|
|
|
|
|
|
| |
Also make overflow depth and max type size configurable through env variables.
This can be helpful at least for debugging.
Fixes #6628.
|
| |
|
|
|
|
|
|
|
|
| |
It's very useful when `pub` is equivalent to "this is crate's public
API", let's enforce this!
Ideally, we should enforce it for local `cargo test`, and only during
CI, but that needs https://github.com/rust-lang/cargo/issues/5034.
|
|
|
|
| |
Quite a few changes, because Chalk got rid of the `ApplicationTy` nesting.
|
|
|
|
|
| |
The lifetime placeholder can be replaced by the static lifetime, and for array
sizes we should just be using a concrete const.
|
| |
|
| |
|
|
|
|
| |
* Chalk very recently (like an hour ago) merged a fix that prevents rust analyzer from panicking. This allows it to be usable again for code that hits those situations. See #6134, #6145, Probably #6120
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
|