Remove -Zfuel.

[cjgillot]

I'm not sure this feature is used. I only found 2 references in a google search, both referring to its introduction.

Meanwhile, it's a global mutable state, untracked by incremental compilation, so incompatible with it.

[rustbot]

r? @wesleywiser

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[tmiasko]

I found it quite useful in the past for bisecting bugs (it could be declared incompatible with incremental compilation if that aspect is an issue).

[JakobDegen]

I agree we should remove it right now, primarily because it's usefulness is significantly diminished by inconsistent use. At some point in the future we should switch to more structured transformations (as opposed to writing to &muts) in which case this can be brought back and we can enforce consistent usage

[bors]

☔ The latest upstream changes (presumably #112775) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #115803) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #116027) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #116144) made this pull request unmergeable. Please resolve the merge conflicts.

[wesleywiser]

Similar to @tmiasko, I've also found this useful in the past. The point that this is inconsistently used is true, but wouldn't it be better to fix that than to remove it entirely?

@pnkfelix suggested that attempting to use -Zfuel with incremental compilation enabled could generate a warning so that devs know it could lead to other problems.

[cjgillot]

We now have a more reliable way to disable optimizations: -Zmir-enable-passes. I recommend using that one for debugging.

[bors]

☔ The latest upstream changes (presumably #115964) made this pull request unmergeable. Please resolve the merge conflicts.

[workingjubilee]

It is more important that the information in the rustc-dev-guide is actually up-to-date, and that "how to debug optimization" is easy and accurate, as people try to actually use it e.g. to analyze and debug their codegen problems. By holding on to this, we are advising much more inexperienced devs to try to make sense of a de facto useless option.

So, do we want random passerby to try to use -Zfuel because we still document it as the thing to do, or do we want them to be informed as to what actually works? If we want -Zfuel to actually work, where is the PR?

[wesleywiser]

r=me with a corresponding PR to adjust rustc-dev-guide

[tmiasko]

The -Zfuel can be used to bisect specific transformation that is incorrect. It makes it trivial to generate diff between working and broken MIR. To locate the source code that is being miscompiled and extract minimized test case. The -Zmir-enable-passes is no alternative for such use cases.

It works perfectly fine even if not every single MIR optimizations uses it - just run bisection, dump MIR at the boundary, and diff between those. If for some reason the current inconsistent use is a deal breaker for others, I can prepare a pull request that will incorporate it directly into a pass manager.

I don't think we should remove it without a proper replacement.

[bjorn3]

-Zfuel is entirely unreliable with parallel rustc, right? The order in which functions get mir optimizations running is non-deterministic and thus which function sees the last fuel consumed.

[nnethercote]

FWIW, I just wrote a patch to refactor the OptimizationFuel type (because it's a bit messy) and then I just discovered this PR...