Remove support for -Zprofile (gcov-style coverage instrumentation)

[Zalathar]

Tracking issue: #42524

MCP: rust-lang/compiler-team#798

---

This PR removes the unstable -Zprofile flag, which enables ”gcov-style” coverage instrumentation, along with its associated -Zprofile-emit configuration flag.

(The profile flag predates and is almost entirely separate from the stable -Cinstrument-coverage flag.)

Notably, the -Zprofile flag:

• Is largely untested in-tree, having only one run-make test that does not check whether its output is correct or useful.
• Has no known maintainer.
• Has seen no push towards stabilization.
• Has at least one severe regression reported in 2022 that apparently remains unaddressed.
  • Regression in code coverage (-Zprofile) at some point after nightly-2021-11-11 #100125
• Is confusingly named, since it appears to be more about coverage than performance profiling, and has nothing to do with PGO.
• Is fundamentally limited by relying on counters auto-inserted by LLVM, with no knowledge of Rust beyond debuginfo.

[rustbot]

r? @chenyukang

rustbot has assigned @chenyukang.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

This PR modifies tests/run-make/. If this PR is trying to port a Makefile
run-make test to use rmake.rs, please update the
run-make port tracking issue
so we can track our progress. You can either modify the tracking issue
directly, or you can comment on the tracking issue and link this PR.

cc @jieyouxu

[Zalathar]

MCP: rust-lang/compiler-team#798

[Zalathar]

Rebased; MCP accepted.

@rustbot ready

[chenyukang]

@bors r+ rollup

[bors]

📌 Commit ce3e14a has been approved by chenyukang

It is now in the queue for this repository.

[jieyouxu]

Technically this is unstable flag, but should this get compat relnotes still?

[Zalathar]

Given the flag’s age and former importance (?), a mention in relnotes is probably warranted. I’ll try to come up with a suggested wording.

[jieyouxu]

@rustbot label +relnotes

[sylvestre]

@Zalathar While not perfect, -Zprofile had advantages over the other option.
Since this change, we haven't been able to get coverage working on again on a medium size rust project:
uutils/coreutils#6857
(the size of the profraw files is way too large for Github).

Am I missing something? If not, would it be possible to reconsider this removal ? Thanks :)

[marco-c]

Agreed with @sylvestre, there are many users, and some large projects might have difficulties switching to source-based coverage as it can be more resource intensive.
If there are no considerable benefits stemming from its removal, it would be ideal to keep it even with its limitations.

[workingjubilee]

My understanding is that the "limitations" are coverage info that can be incorrect by a factor greater than 10, right? It's based on debuginfo, but either not in a way that seems to be very accurate for Rust code, or we are emitting debuginfo in a way that is not useful for it, right?

[Zalathar]

If there are no considerable benefits stemming from its removal, it would be ideal to keep it even with its limitations.

Unfortunately, the existing code was causing real maintenance problems in other parts of the compiler, which was one of the reasons for removing it.

[jieyouxu]

To add, removal of -Zprofile is without prejudice against re-adding the gcov-based coverage instrumentation back under a new unstable feature, provided that:

(1) It uses a more accurate name (one that's not confusing like -Zprofile), and
(2) There are suitable maintainers who sign up to maintain it, and
(3) Passes the review bar for a new unstable feature. E.g. does not cause unwanted maintenance burden on other parts of the compiler (i.e. adding more hacks back)

i.e.

But if somebody out there wants to take the initiative and re-add the feature in a form that would pass the review bar for a new unstable feature, that should be fine.

cc https://rust-lang.zulipchat.com/#narrow/channel/233931-t-compiler.2Fmajor-changes/topic/Remove.20unstable.20.60-Zprofile.60.20.28gcov-style.20c.E2.80.A6.20compiler-team.23798/near/482809968

[workingjubilee]

It would also be nice if someone reported to LLVM about the storage usage being excessive. I feel it is doubtful they have done any optimizations on the profdata format's space usage.