clarify const_prop ICE protection comment#65592
Conversation
|
r? @davidtwco (rust_highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
|
Hm, looks like changing the |
e83191b to
05e4e6b
Compare
05e4e6b to
282403e
Compare
|
Here's an example of taking a ref to an unsized local that's not a function argument... why does that not ICE in const-prop? |
|
r? @wesleywiser |
Currently, we only propagate temporaries, never variables: rust/src/librustc_mir/transform/const_prop.rs Lines 643 to 647 in e5b8c11 Assigning the argument to a variable thwarts |
|
I see. Still, it strikes me as a better test to check for "uninitialized + usized", which matches the actual error condition. Or even just "uninitialized", as that's already impossible code (though maybe there's something useful const-prop can do there?). |
|
That seems reasonable to me! Off-hand, I can't think of anything useful const prop can do with uninitialized values. |
|
So, something like this? (Local build is sill ongoing.) |
ea451d2 to
f907fbe
Compare
|
Okay, tests are passing locally. The PR is ready for review. |
|
📌 Commit f907fbe has been approved by |
…eywiser clarify const_prop ICE protection comment This is based on discussion at https://github.com/rust-lang/rust/pull/64890/files#r334555787. That said, why are function arguments the only unsized locals that could remain uninitialized? Couldn't we also fail to initialize some local but still go on with const_prop, and then hit a line that takes a reference to that? Cc @wesleywiser @oli-obk ; I don't know enough about const-prop to understand why this can happen only for function arguments. ~~The PR includes rust-lang#64890; the only new commit is 05e4e6ba0d5.~~
Rollup of 8 pull requests Successful merges: - #65314 (rustdoc: forward -Z options to rustc) - #65592 (clarify const_prop ICE protection comment) - #65603 (Avoid ICE when include! is used by stdin crate) - #65614 (Improve error message for APIT with explicit generic arguments) - #65629 (Remove `borrowck_graphviz_postflow` from test) - #65633 (Remove leading :: from paths in doc examples) - #65638 (Rename the default argument 'def' to 'default') - #65639 (Fix parameter name in documentation) Failed merges: r? @ghost
This is based on discussion at https://github.com/rust-lang/rust/pull/64890/files#r334555787.
That said, why are function arguments the only unsized locals that could remain uninitialized? Couldn't we also fail to initialize some local but still go on with const_prop, and then hit a line that takes a reference to that? Cc @wesleywiser @oli-obk ; I don't know enough about const-prop to understand why this can happen only for function arguments.
The PR includes #64890; the only new commit is 05e4e6ba0d5.