constify TryFrom<Vec> for array#155616
Conversation
|
r? @jackh726 rustbot has assigned @jackh726. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
9c141c1 to
f59366f
Compare
This comment has been minimized.
This comment has been minimized.
f59366f to
8acdb36
Compare
|
r? libs-api |
|
assigned reviewer seems inactive atm |
|
r? oli is this blocked on figuring out std constification |
|
r? oli-obk |
|
Failed to set assignee to
|
|
Huh why does this affect mir-opts? I think this is fine under std constification, because it tests a very specific use case of a core type like |
@oli-obk do you want me to limit the scope of this PR to that and remove the |
|
I think it's trivial enough, and ppl were more worried about random std types than core types. So it should be fine, and feels like a core use case for const code to push things to a vec but still produce an array |
|
So then @rustbot ready ? |
This still baffles me. Can't merge it without knowing why. |
| StorageLive(_7); | ||
| _7 = copy _4; | ||
| _4 = AddUnchecked(copy _7, const 1_usize); | ||
| _8 = Option::<usize>::Some(copy _7); | ||
| StorageDead(_7); |
There was a problem hiding this comment.
I mean, this is probably an improvement, but what causes it? Do we have mir-opts that are checking constness of functions out of some reason?
|
☔ The latest upstream changes (presumably #149509) made this pull request unmergeable. Please resolve the merge conflicts. |
Related issues #79597, #143773, #133214
this makes
Vecconst Destructalong the way.