feat: Get some more array lengths! #8813
Conversation
Now e.g.
```rust
fn a(b: [u8; 2]) {
}
```
will know about the length of b.
I am not confident that my added byte string parsing is right.
Now we will get the type of `[0u8; 4]`.
|
I've force pushed a rebase of this onto the latest master and added some more examples to the test for byte strings. I now am more confident it's right. Ready for review :) |
|
I think after merging this we can also close #2922? Given that's not really an issue with the assist but just the fact that we have been ignoring const generics completely so far |
I'm not sure! We should write a test for that bug. It probably would, given r-a now does understand most arrays now, assuming there's not something like |
|
Can you check analysis-stats again? I'm a bit worried that this will lead to a regression because we don't support const generics yet, so now trait impls for arrays won't work anymore (inherent impls probably still will, due to the fact that our own unification algorithm doesn't care about the consts...) |
|
(We probably don't have tests for things like A very hacky way of working around this for now might be to continue lowering array sizes to Edit: Ah wait, these sizes will be |
I did, it was not perceptibly changed.
OH WAIT, is this what the deciding that all unknown constants are equal for the purposes of chalk is accomplishing? 🤦🏻♀️ oh my..... However, we're probably (?) getting the right trait more of the time now... Thankfully, since we're an IDE, we have more leeway to do stuff wrong 😆 I shall have to look at the rustc chalk code again to try to understand how they're handling concrete constants. |
So, from the discussion in Zulip, it seems that Chalk is missing a piece to handle unevaluated constants. So |
Fix rust-lang#2922: add unknown length as a condition for a type having unknown. Incorporate reviews: * Extract some of the const evaluation workings into functions * Add fixmes on the hacks * Add tests for impls on specific array lengths (these work!!! 😁) * Add tests for const generics (indeed we don't support it yet)
crates/hir_ty/src/lower.rs
Outdated
| ty: TyKind::Scalar(Scalar::Uint(UintTy::Usize)).intern(&Interner), | ||
| value: ConstValue::Concrete(chalk_ir::ConcreteConst { interned: *len }), | ||
| } | ||
| .intern(&Interner); |
There was a problem hiding this comment.
this can be a call to usize_const?
crates/hir_ty/src/consteval.rs
Outdated
| use crate::{Const, ConstData, ConstValue, Interner, TyKind}; | ||
|
|
||
| /// Extension trait for [`Const`] | ||
| pub trait ConstExtension { |
There was a problem hiding this comment.
I think usually we'd call this ConstExt
crates/hir_ty/src/consteval.rs
Outdated
| } | ||
|
|
||
| /// Extension trait for [`Expr`] | ||
| pub trait ExprEval { |
There was a problem hiding this comment.
I'm not sure why this needs to be an extension trait, as opposed to just a function?
|
bors d+ |
|
✌️ lf- can now approve this pull request. To approve and merge a pull request, simply reply with |
* rename ConstExtension->ConstExt * refactor a manual construction of a Const
|
bors r+ |
lnicola
changed the title
This is built on #8799 and thus contains its changes. I'll rebase it onto master when that one gets merged. It adds support for r-a understanding the length of:
let a: [u8; 2] = ...let a = b"aaa"let a = [0u8; 4]I have added support for getting the values of byte strings, which was not previously there. I am least confident in the correctness of this part and it probably needs some more tests, as we currently have only one test that exercised that part (!).
Fixes #2922.