Consider replacing autocfg with explicit version detection?

[Kixunil]

I get the appeal of autocfg and I would've liked it. Sadly it takes 20+ seconds to compile and many crates depend on this "small and fundamental crate" which leads to prolonging the build quite a lot.

I don't believe it'll ever happen that an older version of Rust will suddenly accept something it didn't accept previously (end definitely not vice-versa - that'd be a bug), so there's no reason to fear "static" version checking. It's just a developer convenience.

[cuviper]

Sadly it takes 20+ seconds to compile

That number is shocking to me -- autocfg takes ~0.38 seconds to compile on my Ryzen 3800X, or ~0.76s in release mode, but recent versions of Cargo always compile build dependencies in debug mode anyway. The total build of num-traits takes about 1.5s. Of course a more constrained machine could take much longer, but proportionally so -- I'd still expect this crate to be a relatively small part of your overall build.

Even if we switched num-traits to version detection, I'd probably still use autocfg for that to standardize how to run rustc and parse its version for comparison. I'm biased as the autocfg author though... 😉

I don't believe it'll ever happen that an older version of Rust will suddenly accept something it didn't accept previously

Historically, some features start getting used before the stable version was released -- e.g. we had some early i128 use with 1.26-nightly, which wasn't available on slightly older nightlies carrying the same version. Of course that particular example matters little now. Another version-independent use is for features that vary by target, like indexmap detects the presence of std, and crossbeam detects the availability of various atomic types to deal with portability.

There's also the future possibility of independent Rust compilers that override RUSTC, much like CC is used, where the versions may have no correspondence to the original rustc at all.

[Kixunil]

That number is shocking to me -- autocfg takes ~0.38 seconds to compile on my Ryzen 3800X, or ~0.76s in release mode

Thanks for heads up, I guess I screwed up something when measuring the first time. It's more reasonable numbers now that I retry it.

I'd probably still use autocfg for that to standardize how to run rustc and parse its version for comparison

version-check would be an alternative, not sure if faster or if there's something wrong with how it does the checking

I'm biased as the autocfg author though...

Nice! :) I was thinking it's a cool crate and an alternative way to use it would be as external binary running the snippets against various versions of rustc to binary search for the version which supports the snippet and then output a piece of code that checks it. This way the operation of checking would be moved to the developer. However considering that it's not as slow as I though perhaps not worth it until someone comes up with badly performing example.

some features start getting used before the stable version was released

Interesting, didn't think of nightlies.

Thanks for explaining other cases as well, will keep it in mind!

Since this is probably not as needed as I thought, feel free to close it if you don't want to bother with changing it.

[cuviper]

It's more reasonable numbers now that I retry it.

Whew, thanks for double-checking!

Since this is probably not as needed as I thought, feel free to close it if you don't want to bother with changing it.

Ok, I think we'll stay as-is.