Rename -Zdebuginfo-for-profiling switch

[zamazan4ik]

The PR was raised from this comment from another stabilization PR: #155942

I renamed -Zdebug-info-for-profiling into -Zdebuginfo-for-profiling before stabilization to be consistent with other debuginfo-related Rustc flags like -C split-debuginfo and -C debuginfo.

One important note is that Clang has the flag under -fdebug-info-for-profiling. I decided that consistency with other Rustc flags is more important here than to be consistent with Clang.

r? folkertdev (as was proposed here)

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[folkertdev]

Neat! you can rebase the other PR once this merges and then we'll nominate it.

In the meantime, can you clean up the stabilization report over there a bit? the text from the template in quote blocks just makes the report longer for no reason, e.g. the tooling section is irrelevant, etc. The process will go faster if you can succinctly describe what we're actually dealing with.

@bors r+ rollup

[rust-bors]

📌 Commit 57e7bf4 has been approved by folkertdev

It is now in the queue for this repository.

[zamazan4ik]

Neat! you can rebase the other PR once this merges and then we'll nominate it.

Sure, will do it.

In the meantime, can you clean up the stabilization report over there a bit? the text from the template in quote blocks just makes the report longer for no reason, e.g. the tooling section is irrelevant, etc. The process will go faster if you can succinctly describe what we're actually dealing with.

Sure, no problem. To be honest, I wanted to do it from the start, but in the Stabilization report template there are the following lines:

Not all parts of the template will apply to every stabilization. If a question doesn’t apply, explain briefly why. Copy everything after the separator and edit it as Markdown. Replace each TODO with your answer.

I've interpreted it as "Copy the whole template, remove nothing from template since it can potentially hide something useful for reviewers, place some N/A comments for non-applicable sections". But if I am wrong in my understanding and reviewers are okay with removing unnecessary parts - I'll happily do the refactoring of the report with removing useless stuff and explaining a bit more some missing details.

Thanks a lot for the review!

[JonathanBrouwer]

@bors r-
#156907 (comment)

[rust-bors]

This pull request was unapproved.

This PR was contained in a rollup (#156907), which was unapproved.

View changes since this unapproval

[folkertdev]

Hmm, is it just a target issue (x86_64 behaves differently from aarch64)? We might need to pin the target using --target = ... and use minicore (see other tests) so that we can run it from anywhere

[zamazan4ik]

Aha, seems like discriminator-based test is architecture-dependent and the amount of emitted discriminators depends on the target platform.

I can perform tests by myself for x86-64 and ARM architectures and limit the test only for these two archs. Is it okay to resolve this error in this way or we need a more generic solution to test on all architectures somehow?

[zamazan4ik]

Hmm, is it just a target issue (x86_64 behaves differently from aarch64)? We might need to pin the target using --target = ... and use minicore (see other tests) so that we can run it from anywhere

Sure, will do it. Do I need to pin to just one architecture or we can enable the test on both - aarch64 and x86-64 as for the most commonly used nowadays.

[folkertdev]

you can specify a target per revision, so you'd get

//@ revisions: DEFAULT-X86 DEFAULT-AARCH64 DEBUGINFO_FOR_PROFILING-X86 DEBUGINFO_FOR_PROFILING-AARCH64

etc. Just those targets is fine for now I think, really we're just testing that the flag has an effect.