Expose `AutoCfg::probe` about autocfg HOT 5 CLOSED

Another use case is checking if the user is able to supply Rust feature gates (like #![feature(…)]).

from autocfg.

Is there any particular reason why this is private?

It's a conservative API choice, not having to worry about how that function looks. Right now it takes T: AsRef<[u8]> and returns Result, which isn't necessarily something I'd want to lock into the API, but it doesn't matter when that's private. There's also a little bit of implicit "magic" for #![no_std] that might have to be explained (and committed to) if we allow sending code directly to this context.

It would be nice to be able to check if #[non_exhaustive] struct Foo is supported without having to return a zero-sized type to make an expression.

You don't have to return Foo -- a block expression works just as well returning the unit () implicitly:

ac.emit_expression_cfg("{ #[non_exhaustive] struct Foo; }", "supports_non_exhaustive");

Rustc will warn of dead code, that Foo is never constructed, but all output is captured from build scripts anyway.

Another use case is checking if the user is able to supply Rust feature gates (like #![feature(…)]).

I think this might deserve a dedicated probe_feature, but nobody has asked for it yet. 🙂

from autocfg.

Something like what anyhow does would probably also be best exposed via custom probes.

autocfg gets a lot of details right regarding how to invoke rustc (propagating rustc flags and --target), but its fairly restricted API means there are many re-implementations of that logic throughout the ecosystem -- and most of them are buggy.

from autocfg.

Another issue that could have been prevented if other crates could use autocfg for their probes: yaahc/eyre#84

from autocfg.

Judging from rust-lang/cargo#11138, doing build probes correctly looks like it is actually going to become even more subtle than it already is. It would be really useful if that functionality could be exposed so it doesn't need to be duplicated everywhere.

from autocfg.