USIZE_MARKER: make sure the function is monomorphized only once #123780
Conversation
|
rustbot has assigned @Mark-Simulacrum. Use |
rustbot
added
S-waiting-on-review
| static USIZE_MARKER: fn(&usize, &mut Formatter<'_>) -> Result = { | ||
| // Make sure this function is only monomorphized once, and not considered cross-crate | ||
| // inlineable. | ||
| #[inline(never)] |
There was a problem hiding this comment.
#[inline(never)] is a suggestion to the optimizer, not a hard requirement. As such this change still doesn't guarantee that the function is only monomorphized once.
https://doc.rust-lang.org/reference/attributes/codegen.html#the-inline-attribute
#[inline(never)]suggests that an inline expansion should never be performed.Note:
#[inline]in every form is a hint, with no requirements on the language to place a copy of the attributed function in the caller.
There was a problem hiding this comment.
Yeah, I don't think there is a way to actually do what USIZE_MARKER wants to do. But I don't think t-libs will let me remove this thing entirely, so using #[inline(never)] seems like an improvement...
Get rid of `USIZE_MARKER` in formatting infrastructure An alternative to rust-lang#123780. The `USIZE_MARKER` function used to differentiate between placeholder and count arguments is never called anyway, so we can just replace the function-pointer-comparison hack with an `enum` and an `unreachable_unchecked`, hopefully without causing a regression. CC `@RalfJung`
…lacrum Get rid of `USIZE_MARKER` in formatting infrastructure An alternative to rust-lang#123780. The `USIZE_MARKER` function used to differentiate between placeholder and count arguments is never called anyway, so we can just replace the function-pointer-comparison hack with an `enum` and an `unreachable_unchecked`, hopefully without causing a regression. CC `@RalfJung`
|
☔ The latest upstream changes (presumably #123819) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Superseded by #123819. |
This entire
USIZE_MARKERthing is a hack and not guaranteed to actually work according to any op.sem proposal I am aware of. Honestly I'd prefer if we could rip it out; trying to provide any kind of guarantee for function pointer identity is basically impossible in Rust. Keeping this hack working is causing major headaches for MIR optimizations.But meanwhile let's at least make it slightly less likely that it will break.