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

@Urgau

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?

@Nemo157

@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?

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

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

@joshtriplett

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.

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

Ah never mind, if that's intended behavior.

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.

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

What's the reason they are not feature gated? That seems like a bug, even if intended. Everything should be gated.

Knowing which feature gates are active requires evaluating cfg's for the crate root. And the cfg's cargo will see through --print cfg can't be feature gated as there is no source code available at that point. Cargo just runs rustc --print cfg once for each target.

why does cargo need to know about this cfg?

Knowing which feature gates are active requires evaluating cfg's for the crate root.

well, we could ban ever using unstable cfgs in the crate root.

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

I think then we have to change our intent. Rustc nightly should behave like stable by default.

We have a similar issue open for cfg(target_feature), see #76842.

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	/// `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),
	];

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

Description

Activity

jieyouxu commented on Nov 21, 2024

taiki-e commented on Nov 21, 2024

jieyouxu commented on Nov 21, 2024

jieyouxu commented on Nov 21, 2024

bjorn3 commented on Nov 21, 2024

jieyouxu commented on Nov 21, 2024

Urgau commented on Nov 21, 2024

jieyouxu commented on Nov 21, 2024

Noratrieb commented on Jan 5, 2025

bjorn3 commented on Jan 5, 2025

jyn514 commented on Apr 16, 2025

RalfJung commented on Oct 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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