RFC: naming groups of configuration with cfg_alias

[tgross35]

This proposal introduces a way to name configuration predicates for easy reuse throughout a crate.

#![cfg_alias(
    x86_linux,
    all(any(target_arch = "x86", target_arch = "x86_64"), target_os = "linux")
)]

#[cfg(x86_linux)]
fn foo() { /* ... */ }
#[cfg(not(x86_linux))]
fn foo() { /* ... */ }

Previous discussion:

• cfg meta variables #831
• Remove unstable cfg target(...) compact feature rust#130780 (comment)
• #t-lang > cfg aliases
• https://internals.rust-lang.org/t/pre-rfc-cfg-attribute-alias/7404/16

Rendered

[tmandry]

I prefer the = form. cfg_attr doesn't seem like a compelling precedent when the predicate goes first with cfg_attr and second with cfg_alias.

I also happen to think the cfg_attr syntax is hard to read, we should avoid replicating that :)

[tgross35]

cfg_attr is definitely not very nice to read or write (though, I don't really know what would have been better here). Reading through it more, I am also starting to prefer = but one concern is that = in config is used for something like equality rather than assignment. Should there be any concern about that here?

I know that also came up in discussion at #3796

[tgross35]

I have updated the syntax to use =

[tgross35]

One other downside: with =, it looks a bit weird when aliasing a single = option

#![cfg_alias(alias = target_os = "linux")]

[tmandry]

Ah, that is a negative. I'll retract my preference then. I'm not crazy about the comma but it's closest to what we have..

[traviscross]

We could choose to require parens there.

[tmandry]

Inspired by the above, one alternative that comes to mind is declarative attribute macros that do the cfg matching for you. I think actually you have to declare two macros, one when the cfg you want is true and one when it is false, so that's a major drawback because it would require repeating the same clause twice.

However, attribute macros (possibly in combination with this feature) would allow a crate to "export" an alias.

[tgross35]

Great point, I'll mention that. One other downside is that with a specific set of config tied to an attribute macro, it wouldn't be easily possible to combine with other config in all or any (could probably be done with the attribute macro's parameters).

Exporting would be quite convenient at times.

[tmandry]

Good point that the macro approach doesn't compose all that well. I wish there was an obvious way to support exporting these.

[tgross35]

For a more radical design, it might be possible to treat aliases as effectively a new kind of macro; something that shares the macro namespace but only expands within cfg. I think this would mean the new macro scoping can be used, so pub use some_alias can make an alias crate-public for another crate to import with use crate_with_alias::some_alias.

It sounds borderline too complex for an otherwise pretty simple feature, but being able to do that could be a nice help if public macros expand to code that contains #[cfg(...)].

With that, it would almost be possible to define the builtin cfg(windows)/cfg(unix) as something like cfg_alias(windows = target_os = "windows") in the prelude (not that we'd have any reason to actually do that).

[mejrs]

I would expect some kind of way to export an alias. I'd be disappointed with a design that wouldn't permit it.

Anyway, your comment about macros made me think of something like...

// library

#[macro_export]
macro_rules! has_atomics {
    () =>  { any(target = a, target = b, .. ) }
}

// crate
#[cfg(has_atomics!())]
fn blah(){}

That has the advantage of not needing a new kind of attribute or new syntax to define an alias. It also makes it obvious when an alias is being used.

Moreover this syntax implies that you can pass arguments.

Let me give an example where this would be useful to me personally. The Python C api has different ABI guarantees. Take PyObject_Vectorcall for example. This function was added in Python 3.9, but only in 3.12 it was added to the Stable ABI.

That means I define the bindings as:

extern "C" {
    #[cfg(any(Py_3_9, all(Py_3_12, not(Py_LIMITED_API))))]
    pub fn PyObject_Vectorcall(..) -> ...

This would be a lot simpler if the syntax is macro-like:

macro_rules! limited {
    ($added_in:ident) =>  { all($added_in, not(Py_LIMITED_API)) }
    ($added_in:ident, $stable_in:ident) =>  { any($stable_in, all($added_in, not(Py_LIMITED_API))) }
}

#[cfg(limited!(Py_3_9, Py_3_12))]
// ...

[tmandry]

I do think @mejrs that this would be quite nice. I suspect it might be difficult to implement, though. Maybe what's needed is an experiment.

[traviscross]

+1 for that.

[oxalica]

#![cfg_alias(some_alias = predicate)]

I'm against syntax cfg_alias(ident = predicate) and prefer cfg_alias(ident, predicate), because of consistency concerns:

1. We already have a very similar cfg_attr(predicate, meta) syntax. cfg_alias(ident, predicate) just flips it and identifier is also a valid meta. Using comma here is most natural and consistent design.
2. path(ident = meta) is a completely new syntax that does not exist anywhere, and contradicts the status quo that = always follows an expression, adding cognitive complexity for human. See current "meta" grammar in reference. Not sure if it will introduce actual implementation complexity.
3. As mentioned above, #![cfg_alias(name = target_os = "linux")] has two = with different meaning which is very confusing. Same situation can also occur when nesting cfg_alias inside other attributes or vice versa.

[programmerjake]

In #3804 (comment) I had meant more that you could use #[cfg(todo)] as an attribute you could add/delete from sections of code, rather than toggling todo's value. So it would be kinda like how todo!() always panics, rather than disappearing if you toggle some flag.

e.g.:

#[cfg(todo)]
pub fn uses_some_api_that_isnt_finished() {
    api::cool_function_that_doesnt_exist_yet();
}

later, once that api is implemented, you can just delete the #[cfg(todo)] line to have your code no longer be skipped.

[traviscross]

I'd probably drop ", including..." here as it makes it more rather than less ambiguous. Alternatively, it'd be OK to say e.g. "including (but not limited to) combining operators such as all, any, and not.

[traviscross]

Have a look at the grammar syntax in the Reference. Probably best to just use that.

[traviscross]

Why module level? Once we eat the cost of making these scoped, I'm curious if there's a reason we shouldn't specify them for other scopes also.

In terms of how we specify the language, it actually makes the specification simpler to have fewer rather than more exceptions. (We can always of course still incrementally stabilize if there are reasons to do so.)

Of course, if we go with a different design, such as leaning into macros somehow, then we could sidestep this question.

[traviscross]

Suggested change

	- It may be possible to have `#[cfg_alias(...)]` work as an outer macro and only
	apply to a specific scope. This likely is not worth the complexity.

Since this has now been added to the RFC, this alternative can be removed.

[traviscross]

Suggested change

	- Substitution vs. evaluation at define time (the question under the
	reference-level explanation)
	- Substitution vs. evaluation at define time (the question under the
	reference-level explanation).

[ogoffart]

The cfg_aliases crate could be mentioned. https://crates.io/crates/cfg_aliases

[kennytm]

to clarify, if we passed --cfg 'foo="bar"', it means cfg_alias(foo, ...) will be also conflicting right?

[joshtriplett]

Please add some details on hygiene. For instance, what happens if you write a cfg_alias on a macro_defining_a_fn!()? Does the macro "see" the alias set, ignoring hygiene? Or do you need to pass the identifier into the macro (e.g. macro_defining_a_fn!(the_alias), so that hygiene works? I would expect the latter.

[traviscross]

cc @ehuss @eholk

[joshtriplett]

Suggested change

	reuse in multiple crates.
	reuse in multiple crates.
	- We could add a visibility to the syntax, allowing a crate to export a cfg alias for use by other crates.