Don't print unsupported split-debuginfo modes with -Zunstable-options

[Alexendoo]

Currently unsupported split-debuginfo options are enabled by -Zunstable-options, for projects that have -Zunstable-options for other reasons this can be an unexpected interaction

This PR makes it so that --print split-debuginfo -Zunstable-options doesn't print unsupported modes, so that a cargo config of e.g.

[profile.dev]
split-debuginfo = "unpacked"

Would not cause an unsupported mode to be enabled on x86_64-pc-windows-msvc

[rustbot]

r? @b-naber

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

[klensy]

Looks related rust-lang/cargo@64a1f20

[b-naber]

Sorry for the late reply.

I don't really know what this is about (should probably re-assign this), but I'm wondering why would anybody ever use this option, i.e. why would it make sense to enable an unsupported mode? Also would anybody ever rely on unsupported modes through -Zunstable-options?

[Alexendoo]

I don't really know what this is about (should probably re-assign this), but I'm wondering why would anybody ever use this option, i.e. why would it make sense to enable an unsupported mode? Also would anybody ever rely on unsupported modes through -Zunstable-options?

I thought the same initially and went to just remove the behaviour, but there are some tests that explicitly use the unsupported modes so I was no longer sure

Looks related rust-lang/cargo@64a1f20

Should be unrelated to that change, cargo is doing the right thing as it asks rustc what modes are supported with --print=split-debuginfo, but -Zunstable-options --print=split-debuginfo prints all the modes even if they aren't supported

We could change just the --print part and keep the other behaviour, that would mean cargo configs with profile.dev.split-debuginfo = "unpacked" with -Zunstable-options would no longer use an unsupported mode on some platforms, but it could still be opted into explicitly through rustflags. I'll go ahead and implement that since it would mean no new flag is needed

[b-naber]

I don't really know what this is about (should probably re-assign this), but I'm wondering why would anybody ever use this option, i.e. why would it make sense to enable an unsupported mode? Also would anybody ever rely on unsupported modes through -Zunstable-options?

I thought the same initially and went to just remove the behaviour, but there are some tests that explicitly use the unsupported modes so I was no longer sure

Can you say which tests those were?

[Alexendoo]

This was the main one, there was also this arm in compiletest but I don't remember if that was hit in CI or not

[b-naber]

The changes look reasonable to me, but I'm not sure I fully grasp the implications of this change. So the change only prevents unsupported split-debuginfo options being printed in print_crate_info. How does cargo or any other crate that directly relies on rustc use this information?

[Alexendoo]

Cargo calls rustc --print=split-debuginfo to determine if a mode should be enabled, on x86_64-pc-windows-msvc that'll result in

$ rustc --print split-debuginfo
packed

So with the config

[profile.dev]
split-debuginfo = "unpacked"

It will determine that unpacked isn't supported and so won't pass -C split-debuginfo=unpacked to the rustc commands used for compiling/checking

When you have -Zunstable-options in RUSTFLAGS/a cargo config like we do in Clippy though the result is different

$ rustc --print split-debuginfo -Zunstable-options
off
packed
unpacked

Cargo then thinks rustc supports unpacked and will pass -C split-debuginfo=unpacked, even though msvc does not properly support it. After this change it would only print packed as above

[b-naber]

Thanks for the explanation. So it only uses those options for validation? And it doesn't currently error when an option provided in the toml file isn't supported on that machine?

If it doesn't error, does it just generate debugging information that is "unusable" on that machine?

[Alexendoo]

If you have an unsupported (as determined through rustc --print split-debuginfo) mode in the config cargo will ignore it, you get the default mode for the platform

There's no error/warning from cargo

[b-naber]

Thanks for clarifying this. This seems like the correct fix then. Though I do wonder why this was introduced in the first place then.

Could you maybe open a PR to remove the following line from the split-debuginfo section on this page: https://doc.rust-lang.org/rustc/codegen-options/index.html#split-debuginfo

Attempting to use an unsupported option requires using the nightly channel with the -Z unstable-options flag.

[b-naber]

@bors r+ rollup

[bors]

📌 Commit fda3c9f has been approved by b-naber

It is now in the queue for this repository.