'Unknown' int/float types actually never exist as such, they get replaced by
type variables immediately. So the whole `Uncertain<IntTy>` thing was
unnecessary and just led to a bunch of match branches that were never hit.
4689: Implement return position impl trait / opaque type support r=matklad a=flodiebold
This is working, but I'm not that happy with how the lowering works. We might need an additional representation between `TypeRef` and `Ty` where names are resolved and `impl Trait` bounds are separated out, but things like inference variables don't exist and `impl Trait` is always represented the same way.
Also note that this doesn't implement correct handling of RPIT *inside* the function (which involves turning the `impl Trait`s into variables and creating obligations for them). That intermediate representation might help there as well.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
This is working, but I'm not that happy with how the lowering works. We might
need an additional representation between `TypeRef` and `Ty` where names are
resolved and `impl Trait` bounds are separated out, but things like inference
variables don't exist and `impl Trait` is always represented the same
way.
Also note that this doesn't implement correct handling of RPIT *inside* the
function (which involves turning the `impl Trait`s into variables and creating
obligations for them). That intermediate representation might help there as
well.
4651: Use first match branch in case of type mismatch, not last r=kjeremy a=flodiebold
The comment says this was intentional, but I do agree with #4304 that it makes
more sense the other way around (for if/else as well).
Fixes#4304.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
4641: Upgrade Chalk r=matklad a=flodiebold
Chalk newly added TypeName::Never and Array; I implemented the conversion for
Never, but not Array since that expects a const argument.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Function pointers can be 'higher-ranked' over lifetimes, which is why they're
not an application type in Chalk, but since we don't model lifetimes it doesn't
matter for us yet.
4497: Create LowerCtx on the fly r=matklad a=edwin0cheng
Previously we create `LowerCtx` at the beginning of lowering, however, the hygiene content is in fact changing between macro expression expanding.
This PR change it to create the `LowerCtx` on the fly to fix above bug.
However, #4465 is not fixed by this PR, the goto-def is still not work yet. It only fixed the infer part.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
4394: Simplify r=matklad a=Veetaha
4414: Highlighting improvements r=matklad a=matthewjasper
- `static mut`s are highlighted as `mutable`.
- The name of the macro declared by `macro_rules!` is now highlighted.
Co-authored-by: veetaha <veetaha2@gmail.com>
Co-authored-by: Matthew Jasper <mjjasper1@gmail.com>
This fixes an issue where the following code sample would fail to infer
the type contained in the option:
```rust
fn main() {
let mut end = None; // TODO: Fix inference for this in RA
loop {
end = Some(true);
}
}
```
4175: Introduce HirDisplay method for rendering source code & use it in add_function assist r=flodiebold a=TimoFreiberg
Next feature for #3639.
So far the only change in the new `HirDisplay` method is that paths are qualified, but more changes will be necessary (omitting the function name from function types, returning an error instead of printing `"{unknown}"`, probably more).
Is that approach okay?
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
E.g. in
```rust
match x {
1 => function1,
2 => function2,
}
```
we need to try coercing both to pointers. Turns out this is a special case in
rustc as well (see the link in the comment).
Divergence here means that for some reason, the end of a block will not be
reached. We tried to model this just using the never type, but that doesn't work
fully (e.g. in `let x = { loop {}; "foo" };` x should still have type `&str`);
so this introduces a `diverges` flag that the type checker keeps track of, like
rustc does.
4173: Use core instead of std for builtin derive macros r=edwin0cheng a=edwin0cheng
Fixed#4087.
We can't use `$crate` here right now because :
1. We have to able to detect `macro` 2.0 in collecting phase for finding `rustc_builtin_macro` attrs.
2. And we have to make hygiene works for builtin derive macro.
r= @flodiebold
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
So e.g. if we have `fn foo<T: SomeTrait<u32>>() -> T::Item`, we want to lower
that to `<T as SomeTrait<u32>>::Item` and not `<T as SomeTrait<_>>::Item`.
4106: Fix wrong substitution code r=matklad a=flodiebold
We need to shift in when we're substituting inside a binder.
This should fix#4053 (it doesn't fix the occasional overflow that also occurs on the Diesel codebase though).
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
We need to shift in when we're substituting inside a binder.
This should fix#4053 (it doesn't fix the occasional overflow that also occurs
on the Diesel codebase though).
4023: Fix another crash from wrong binders r=matklad a=flodiebold
Basically, if we had something like `dyn Trait<T>` (where `T` is a type parameter) in an impl we lowered that to `dyn Trait<^0.0>`, when it should be `dyn Trait<^1.0>` because the `dyn` introduces a new binder. With one type parameter, that's just wrong, with two, it'll lead to crashes.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Basically, if we had something like `dyn Trait<T>` (where `T` is a type
parameter) in an impl we lowered that to `dyn Trait<^0.0>`, when it should be
`dyn Trait<^1.0>` because the `dyn` introduces a new binder. With one type
parameter, that's just wrong, with two, it'll lead to crashes.
Fixes a lot of false type mismatches.
(And as always when touching the unification code, I have to say I'm looking
forward to replacing it by Chalk's...)
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.