Add basic support for array lengths in types #8799
Conversation
|
the ci comes back i see, those were indeed not to be updated, yet. well, fyi, some nightly will break these tests when you update ;-)
|
This recognizes `let a = [1u8, 2, 3]` as having type `[u8; 3]` instead of the previous `[u8; _]`. Byte strings and `[0u8; 2]` kinds of range array declarations are unsupported as before. I don't know why a bunch of our rustc tests had single quotes inside strings un-escaped by `UPDATE_EXPECT=1 cargo t`, but I don't think it's bad? Maybe something in a nightly?
|
Good idea to start with array expressions, that sidesteps the whole const expression body lowering topic. I'll probably review this this evening. |
Quite the opposite, in fact :) Today's nightly. But I'm reverting it because it's not right for stable, which is nominally the target for the tests. |
| // we were previously assuming this to be true, I'm not whether true or false on | ||
| // unknown values is safer. | ||
| (_, _) => true, |
There was a problem hiding this comment.
IIRC this is where you want to "defer" an obligation while returning true so that it's "conditionally true" (and if the condition is the same equality check then it's basically "unknowable", instead of "known true/false"), but @nikomatsakis or someone else familiar with Chalk would have to explain how that integrates.
There was a problem hiding this comment.
Under which conditions does this happen in rustc?
|
LGTM. I'd be interested in what @nikomatsakis or @rust-lang/wg-traits think about handling unknown/unevaluatable consts though. Also, if you haven't yet, would you mind running |
|
booped into Zulip for the traits wg: https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-traits/topic/Handling.20non.20evaluatable.20constants'.20equality/near/238386348 |
new: old: I'm going to consider that likely an insignificant difference, which does make a fair bit of sense given we are not doing much work to achieve this. |
|
I've addressed the actionable review feedback. Currently I'm about halfway through doing #2834 (comment), #540, etc, to be able to parse literals in RA, which we can use to add lengths to byte strings and to cheat on putting lengths on arrays with literal lengths. This work will be in a future PR based on this one for ease of review and I'll file that when I get it done. |
|
bors r+ |
8813: Get some more array lengths! r=lf- a=lf- 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. Co-authored-by: Jade <software@lfcode.ca>
This recognizes
let a = [1u8, 2, 3]as having type[u8; 3]insteadof the previous
[u8; _]. Byte strings and[0u8; 2]kinds of rangearray declarations are unsupported as before.
I don't know why a bunch of our rustc tests had single quotes inside
strings un-escaped by
UPDATE_EXPECT=1 cargo t, but I don't think it'sbad? Maybe something in a nightly?