-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Inlining/flattening of format_args!() accidentally exposed as stable through const #139136
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
Comments
Remove 'simple array' lowering of format_args!(). format_args!() uses a simpler (faster to compile) lowering in simple cases. However, selecting that case is somewhat complicated, as it does not work if any argument beyond the first one contains a yield point, so we have to check for that. As part of the solution for rust-lang#92698 and rust-lang#139136, it might need to get even more complicated, checking for any lifetime-extended temporaries or any const-promotable expressions. This is an experiment to see the impact of just removing this optimazation. This has been tried before with [slightly negative results](rust-lang#106770 (comment)), but maybe things have changed by now. :)
It seems worth at least cratering this to see whether we can go back to a "clean state" before extending the const-eval capabilities around |
PR for the crater run: #139624 |
Don't allow flattened format_args in const. Fixes rust-lang#139136 and rust-lang#139621 by breaking the 'flattened format_args' cases. This is a breaking change. Let's try a crater run.
Turns out that wasn't the error. I did do it right (by properly marking the new_v1/new_v1_formatted/none functions as non-const). The problem was introduced in Rust 1.86.0 by this PR: #135139 |
format_args!()
can currently only be stored (and used later) if it has no arguments:However,
format_args!("1 + 1 = {}", 2)
is optimized to (effectively)format_args!("1 + 1 = 2")
as part of ast lowering.To avoid allowing more code because of this optimization, the lowering results in a slightly different expansion that would still result in the same error. (By using
&none()
rather than&[]
.)However, I had failed to consider the effect in aconst
:However, because of #135139, we now have:
(The expression for Y is subject to format_args inlining/flattening. The one for Z is not.)
It means there can be code out there that relies on format_args inlining/flattening working the way it does today.
Two solutions:
Y
example fail to compile as well. This would be a (small?) breaking change. Don't allow flattened format_args in const. #139624The text was updated successfully, but these errors were encountered: