Nightly-only cfg gating like #[cfg(target_has_atomic)] is confusing

[jieyouxu]

EDIT: this is intended that cfg(target_has_atomic) is nightly-only (not feature-gated), but I find it still very confusing.

---

Note that #[cfg(target_has_atomic)] is not to be confused with #[cfg(target_has_atomic = "8")].

Given a snippet (just rustc --crate-type="lib", no additional --cfg flags)

#[cfg(target_has_atomic)]
fn foo() {}

• On stable 1.82.0 this produces no warnings.
• On nightly 2024-11-20 this produces a dead_code warning indicating target_has_atomic cfg is enabled.

warning: function `foo` is never used
 --> src/lib.rs:2:4
  |
2 | fn foo() {}
  |    ^^^
  |
  = note: `#[warn(dead_code)]` on by default

AFAICT there is no test coverage for the intended behavior of just #[cfg(target_has_atomic)] alone, other test coverage is mostly for check-cfg.

cc @Urgau since you worked on builtin-cfg rejection do you know anything about if this is intended, and if so, what is the intended behavior here?

[jieyouxu]

@Nemo157 has another example:

For a given snippet and rustc --cfg='foo="bar"' --crate-type=lib,

#[cfg(foo)] pub fn foo() -> usize { 1 }
#[cfg(foo = "bar")] pub fn bar() -> usize { 2 }
#[cfg(target_has_atomic)] pub fn target_has_atomic() -> usize { 3 }
#[cfg(target_has_atomic = "8")] pub fn target_has_atomic_8() -> usize { 4 }

On stable 1.82.0 this codegens

example::bar:
        mov     eax, 2
        ret
example::target_has_atomic_8:
        mov     eax, 4
        ret

On nightly 2024-11-20 this codegens

example::bar:
        mov     eax, 2
        ret
example::target_has_atomic:
        mov     eax, 3
        ret
example::target_has_atomic_8:
        mov     eax, 4
        ret

Further indicating that target_has_atomic has become active by default, but is this intentional?

[taiki-e]

This cfg has been added in #106856, and means any(target_has_atomic = "8", target_has_atomic = "16", target_has_atomic = "32", ...).

[jieyouxu]

Oh... This is nightly-gated but it is not feature-gated

[jieyouxu]

cc @joshtriplett since you r+'d #106856 do you know if there a particular reason why cfg(target_has_atomic) was nightly-gated and not feature-gated? Just asking in case there's a particular reason.

[bjorn3]

All unstable cfg's are nigtly gated and not feature gated.

[jieyouxu]

Ah never mind, if that's intended behavior.

[Urgau]

All unstable cfg's are nigtly gated and not feature gated

That's not true, most unstable cfgs are both nightly gated and feature gated,

rust/compiler/rustc_feature/src/builtin_attrs.rs

Lines 17 to 40 in 717f5df

	/// `cfg(...)`'s that are feature gated.
	const GATED_CFGS: &[GatedCfg] = &[
	// (name in cfg, feature, function to check if the feature is enabled)
	(sym::overflow_checks, sym::cfg_overflow_checks, Features::cfg_overflow_checks),
	(sym::ub_checks, sym::cfg_ub_checks, Features::cfg_ub_checks),
	(sym::target_thread_local, sym::cfg_target_thread_local, Features::cfg_target_thread_local),
	(
	sym::target_has_atomic_equal_alignment,
	sym::cfg_target_has_atomic_equal_alignment,
	Features::cfg_target_has_atomic_equal_alignment,
	),
	(
	sym::target_has_atomic_load_store,
	sym::cfg_target_has_atomic,
	Features::cfg_target_has_atomic,
	),
	(sym::sanitize, sym::cfg_sanitize, Features::cfg_sanitize),
	(sym::version, sym::cfg_version, Features::cfg_version),
	(sym::relocation_model, sym::cfg_relocation_model, Features::cfg_relocation_model),
	(sym::sanitizer_cfi_generalize_pointers, sym::cfg_sanitizer_cfi, Features::cfg_sanitizer_cfi),
	(sym::sanitizer_cfi_normalize_integers, sym::cfg_sanitizer_cfi, Features::cfg_sanitizer_cfi),
	// this is consistent with naming of the compiler flag it's for
	(sym::fmt_debug, sym::fmt_debug, Features::fmt_debug),
	];

Btw, the current cfg feature gating system assumes that all the values are gated but that doesn't map well for target_has_atomic where only the value-less should be feature gated. We would need to do extend the system to permit feature gating only some values for a cfg name.

[jieyouxu]

I'm going to reopen this issue as a possible enhancement to make these kinds of gating less confusing...