5355: Add a license field to all the crates r=matklad a=JohnTitor
Some are unnecessary but it's okay to have it, I think.
cc https://github.com/rust-lang/rust/issues/74269
Co-authored-by: Yuki Okushi <huyuumi.dev@gmail.com>
5331: Fix#4966 r=flodiebold a=flodiebold
We add a level of binders when converting our function pointer to Chalk's; we need to remove it again on the way back.
Fixes#4966.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
This adds the type inference to Union types and add a small test case
for it, ensuring it keeps working in future.
Fixes: #5277
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
We need to add the `T: Index<Arg>` obligation to be resolved later as well,
otherwise we can't make inferences about `Arg` later based on the `Index` impls.
This still doesn't fix indexing with integer variables though; there's a further
problem with Chalk floundering because of the variable, I think.
5149: Implement Chalk variable kinds r=flodiebold a=flodiebold
This means we need to keep track of the kinds (general/int/float) of variables in `Canonical`, which requires some more ceremony. (It also exposes some places where we're not really dealing with canonicalization correctly -- another thing to be cleaned up when we switch to using Chalk's types directly.)
Should fix the last remaining issue of #2534.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
This means we need to keep track of the kinds (general/int/float) of variables
in `Canonical`, which requires some more ceremony. (It also exposes some places
where we're not really dealing with canonicalization correctly -- another thing
to be cleaned up when we switch to using Chalk's types directly.)
Should fix the last remaining issue of #2534.
This makes the intention of inherent vs. trait impls somewhat more
clear and also fixes (?) an issue where trait impls with an unresolved
trait were added as inherent impls instead (hence the test changes).
5124: (Partially) fix handling of type params depending on type params r=matklad a=flodiebold
If the first type parameter gets inferred, that's still not handled correctly; it'll require some more refactoring: E.g. if we have `Thing<T, F=fn() -> T>` and then instantiate `Thing<_>`, that gets turned into `Thing<_, fn() -> _>` before the `_` is instantiated into a type variable -- so afterwards, we have two type variables without any connection to each other.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
If the first type parameter gets inferred, that's still not handled correctly;
it'll require some more refactoring: E.g. if we have `Thing<T, F=fn() -> T>` and
then instantiate `Thing<_>`, that gets turned into `Thing<_, fn() -> _>` before
the `_` is instantiated into a type variable -- so afterwards, we have two type
variables without any connection to each other.
