Support for version-based code generation

[taiki-e]

This rewrites the const_fn attribute to support the following four syntaxes:

use const_fn::const_fn;

// 1.36 and later compiler (including beta and nightly)
#[const_fn("1.36")]
pub const fn version() {
    /* ... */
}

// nightly compiler (including dev build)
#[const_fn(nightly)]
pub const fn nightly() {
    /* ... */
}

// `cfg(...)`
#[const_fn(cfg(...))]
pub const fn cfg() {
    /* ... */
}

// `cfg(feature = "...")`
#[const_fn(feature = "...")]
pub const fn feature() {
    /* ... */
}

This does not provide any special support for beta. This is because unlike nighty there are no unstable features (features available in beta are already stabilized, so I think it is preferable to specify that version).

Closes #15

[jhpratt]

Just for reference, when cfg_version is implemented (if it's not already), the lsng team decided it was best to have nightly be treated as one version prior — essentially the current beta. This is because there's no guarantee that a feature available in a given nightly will land two releases later.

I can pull up a reference tomorrow if you'd like, as I'm on mobile right now. I believe I'm remembering it correctly, though.

Also, may I suggest you check out the version_check crate? It's widely used and does pretty much the same thing as you're doing in the build script.

[taiki-e]

Just for reference, when cfg_version is implemented (if it's not already), the lsng team decided it was best to have nightly be treated as one version prior — essentially the current beta. This is because there's no guarantee that a feature available in a given nightly will land two releases later.

Hmm, I think that discussion has not been finished yet: rust-lang/rust#64796 (comment)

Also, may I suggest you check out the version_check crate? It's widely used and does pretty much the same thing as you're doing in the build script.

Sounds good.

[taiki-e]

It currently only accepts string literals as version requirements, like cfg_version does.

[taiki-e]

Filed #19

[taiki-e]

To use the nightly only unstable feature, it needs to enable the feature at crate-level, and in any case, it needs build-script. So, this may not be very useful in practice, but I'll keep it for now.

[jhpratt]

Hmm, I think that discussion has not been finished yet: rust-lang/rust#64796 (comment)

Looks like I must've missed that comment; I just remembered this comment off the top of my head. Changing the behavior would of course be a breaking change, so it's something to be mindful of at the least.

---

Is it common/accepted practice to write details to a file, which is later accessed as part of the compilation process? It's a neat trick, but I don't think I've ever seen it anywhere before. I've always used rustc cfgs, prefixed with something unique to the crate.

[taiki-e]

Is it common/accepted practice to write details to a file, which is later accessed as part of the compilation process? It's a neat trick, but I don't think I've ever seen it anywhere before. I've always used rustc cfgs, prefixed with something unique to the crate.

cfgs have no values, so version info should be output another way. (Of course, we can also output a cfg like const_fn_version_is_1_36_0, but we'll need a lot of const or if statements to convert it to version info)

I don't know how widely it is used, but at least I think bindgen users are using it.

[taiki-e]

bors r+

There may be minor bugs and lack of documentation, but I think the implementation is ok with this.
After merging this and #18, I plan to make a new release.

[bors]

Build succeeded:

• ci