Binary size creep on Fuchsia after commit 5ced3da about rust HOT 6 OPEN

The rustc-perf result for #125853 is neutral. Also the code there doesn't change any behaviors in mir tests.
So you might want to bisect again.

Edit: If you want, I could open a try PR to revert suspicious c036594 which I think could be the most responsible in #125853.

@rustbot label +E-needs-mcve

from rust.

Interesting. I've double-checked the bisection and am confident this is the commit after which we observe the size creep. That said, I have no theory of the case for why this is occurring, so I may just be engaging in a post hoc ergo propter hoc fallacy. If the perf result is neutral, that's good evidence that something else may be responsible.

If it's not too much trouble, please open the try PR to see if that sheds more light on what's going on. Note that this is not a blocker for Fuchsia; we just wanted to alert you that we had observed the size creep.

from rust.

Btw, how did you build rustc on fuchsia ? Did you enable tracing facility ?

from rust.

The tracing level could maybe impact rustc's size but not the produced binaries size 🤔 .

Similarly, a try build of the mentioned revert shouldn't provide much more information, unless the fuchsia team tries it to see if it fixes the issue.

What could be interesting though is the simplest way to execute the "binary size creep check", and then we could try it within the fuchsia docker image.

from rust.

@amanda-tait @erickt @tmandry @djkoloski @P1n3appl3 #124032 landed a few PRs before #125853 and definitely had binary size increases, did your size checks also flag that one up?

from rust.

@rustbot label -needs-triage +O-fuchisa +T-compiler +I-heavy

from rust.