Issues that would encourage a decision to disable incremental in 1.60 stable

[trevyn]

https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html states:

We are not presently aware of other issues that would encourage a decision to disable incremental in 1.60 stable

I would like to raise #47384 (comment) as an issue that would encourage a decision to disable incremental in 1.60 stable.

#[used(compiler)] and #[used(linker)], which can mitigate this issue, are currently behind a feature gate: #93798

[wesleywiser]

Thanks for raising this issue! In my opinion, we would not disable incremental compilation in the 1.60 stable release because of that issue for a few reasons:

• Is this actually an incremental compilation issue? Incremental compilation does not factor into the process of deciding what items are used. It does however change the default number of codegen units we hand to LLVM and, eventually, the linker. It seems more likely to me that when incremental compilation is enabled, the higher number of CGUs results in the static item being placed in an otherwise unused CGU which is then discarded by the linker. If my hunch is correct, then a user can fix (or trigger) this issue by changing the number of CGUs rustc uses which is an option independent of incremental compilation.
• Severity of issue: the linked bug does not seem to result in either frequent ICEs for the compiler or unsound code to be accepted by the compiler resulting in miscompilations. Given how important incremental compilation is to managing compile times during the development process, we have to take the decision to disable incremental compilation very seriously and, in my opinion, the linked issue does not rise to the level necessary to warrant disabling incremental compilation.
• Status quo: The linked issue has been open since 2019. We've had many releases since that time where this issue has been broken. I don't see any new rationale in the thread for why we should disable incremental compilation because of this issue when we haven't done so in the past.

Therefore, I don't think that issue should cause us to disable incremental compilation on the 1.60 release branch.

cc @pnkfelix @cjgillot @Aaron1011 @michaelwoerister for their thoughts as well.

[Aaron1011]

Incremental compilation does not factor into the process of deciding what items are used.

Incremental compilation does determine whether or not we decide to re-use a particular CGU, so it's plausible that incremental compilation could be causing this bug.

[wesleywiser]

That's true. The linked comment isn't 100% clear but since they don't complain about it periodically not working (thus requiring a cargo clean), I interpreted it to mean that they consistently see this issue. In particular, this sentence (emphasis mine) strongly suggests to me it's actually the higher number of CGUs that's at fault:

With --release, the #[used] static items from an otherwise unreachable module appeared in the resulting binary.

[michaelwoerister]

@wesleywiser's assessment sounds accurate to me. Incremental compilation increases the number of CGU's that the compiler generates, and it does make decisions if a CGU will be re-compiled or used from the cache. But as far as I know, the linker will always see the complete set of CGUs/object files (where some of them might be from a previous compilation session). It does not like this issue is introduced by a failure of re-compiling something due to faulty dependency tracking. This could be verified by trying to compile affected crates with CARGO_INCREMENTAL=0 RUSTFLAGS=-Ccodegen-units=99999 cargo build. Or vice versa, compile with incr. comp. enabled but -Ccodegen-units=16.

Given that this is a long standing bug and it is at least questionable whether incr. comp. is the root cause, disabling it doesn't sound like the right approach to me. Better to try and find out what the actual root cause is.

[Mark-Simulacrum]

I'm going to go ahead and close this as we're not intending to block incremental on it for 1.60, and #47384 will remain open to track the actual bug here.