-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.