@cuviper Just a friendly ping. Did you have any thoughts or feedback on this?

I think I would rather avoid the channel stuff, especially since there are knobs like RUSTC_BOOTSTRAP that can enable features on stable/beta, and that's further complicated by conditions like rust-lang/rust#77802.

If we just support probing features with an actual rustc invocation, I think we'll be on firmer ground. And IMO, responsible use needs to consciously probe not just that a feature exists, but also that it works the way you expect (to the extent that's possible with just a compilation test).

• set_feature() - Sets a feature to be allowed before each subsequent probe. Basically the same idea as what is being done with no_std in Add getter no_std() and setter set_no_std(bool) #27. This doesn't do anything on stable/beta channels, which is good as it allows probes to succeed still if running on a later rustc version where the desired feature may have already been stabilized.

I don't think that should be conditional at all -- just do as asked and let further use fail when that feature isn't actually supported.

Wow, TIL about RUSTC_BOOTSTRAP. Looks like this approach might be too narrow when it comes to probing feature-gated stuff. With that in mind, I think I agree that avoiding the channel stuff completely would be best.

And IMO, responsible use needs to consciously probe not just that a feature exists, but also that it works the way you expect (to the extent that's possible with just a compilation test).

I completely agree with you on this one. Taking a second look, I don't know if probe_feature() would actually be helpful. The API should probably encourage people to check that code runs correctly when features are enabled, since something being gated behind a feature means it is in development and subject to change.

What if this was simplified to literally just be:

• set_feature() - Inserts the feature into each subsequent probe.
• unset_feature() - Removes the feature from each subsequent probe, if it was set.

This would drop any need to parse rustc output for channel, and allows for stuff like:

let mut ac = autocfg::new();

ac.set_feature("step_trait");
ac.emit_has_trait("core::iter::Step");
ac.unset_feature("step_trait");
// Other probes that don't require the feature.

Do you think this would be sufficient?

You can also clone() before trying something with a feature, so we only need the setter -- but I think unset is fine too.

Bikeshedding the name -- is set/unset the best choice? Maybe add/remove or enable/disable?
(#27 uses set, but that's controlling a single value rather than a collection.)

Changing the names is fine with me. You're right, I think I went with set because #27 used set, but I'm not overly attached to it. I feel like I prefer enable/disable over add/remove in this context, since users will be "enabling" the feature in future probes.

Since this PR includes quite a bit of stuff that isn't going to be included, it seemed easier to open another PR. Hope you don't mind, I'm closing this in favor of #35.