build: gate utilities by target support

[xtqqczze]

Fix compilation errors on some platforms that caused cargo check to fail.

Closes #14912.
Related: #11019

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/misc/io-errors (fails in this run but passes in the 'main' branch)
Note: The gnu test tests/tail/tail-n0f is now being skipped but was previously passing.

[codspeed]

Merging this PR will not alter performance

⚠️ 27 benchmarks spent significant time in system calls

System calls cannot be consistently instrumented, so they are not included in the measure, which understates the real cost. Please switch to the Walltime instrument to accurately measure system calls.

Measurement and system calls

• du_wide_tree[(5000, 500)]
• du_all_wide_tree[(5000, 500)]
• dd_copy_64k_blocks
• du_deep_tree[(100, 3)]
• cut_fields_newline_delim
• dd_copy_1m_blocks
• single_date_now
• dd_copy_8k_blocks
• dd_copy_partial
• cp_preserve_metadata[(5, 4, 10)]
• …and 17 more

✅ 37 untouched benchmarks
⏩ 434 skipped benchmarks¹

---

_{Comparing xtqqczze:not-supported-target (3fb2a7b) with main (175f6e1)²}

Footnotes

1. 434 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (b8657e8) during the generation of this report, so 175f6e1 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[oech3]

I don't like this solution. This is already covered by feature.

[xtqqczze]

I would like to get cargo clippy --workspace --all-targets --all-features working.

[oech3]

It does not making a sense to clippy unsupported part.

[oech3]

At least, I think distributor does not want to distribute stubs if Mafefile included a bug someday. compile_error! is better behavior for distributors.

[oech3]

You should ask upstream to auto-skip clippy when compile_error! appear.
Stub should not be distributed accidentaly anyway.

[oech3]

rust-lang/cargo#1197

[xtqqczze]

We already use supports stubs for chcon and runcon: #8795

[oech3]

People on MSYS2 could try to replace system binary with main's binary, or replace cygwin binary with windows binary if cygpath is not an issue. In the case, people can incorrectly override proper nohup.exe by stub nohup.exe and break the system. (*con are accidentally exception since MSYS does not have them. But we should not have)

[xtqqczze]

I guess we could avoid stubs with:

#![cfg_attr(not(unix), no_main)]
#![cfg(unix)]
uucore::bin!(uu_nohup);

Then we get a linker error, but at least no compile errors.

[oech3]

How about just removing compile_error!?

[xtqqczze]

The crate fails compile for non-Unix, so it seems the only options are to use a stub, linker error, or compile error.

[oech3]

I passed cargo check -p uu_true with #![no_main] only. So it looks best solution.

[oech3]

I'll investigate what I can do for bin! macro itself.

[oech3]

not(clippy)

[xtqqczze]

not(clippy)

Doesn't help for compile errors, e.g. with cargo check.

[oech3]

Linker error should happen also for multicall-call binary.

[xtqqczze]

Linker error should happen also for multicall-call binary.

How can I test this?

[oech3]

cargo check --no-default-features --features nohup

[xtqqczze]

Closing, work is tracked by #14912.

[xtqqczze]

Reopening for CI.