Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should treat "1.N" as false on 1.N nightly? #27

Closed
taiki-e opened this issue Sep 29, 2020 · 3 comments · Fixed by #35
Closed

Should treat "1.N" as false on 1.N nightly? #27

taiki-e opened this issue Sep 29, 2020 · 3 comments · Fixed by #35

Comments

@taiki-e
Copy link
Owner

taiki-e commented Sep 29, 2020

time-rs/time#281 (comment)

I'm ok if change the implementation to treat const_fn("1.N") as false on 1.N-nightly (I don't have a very strong opinion), but I've never actually seen a crate using a build script based on that logic. (In any case, once cfg-version is stable, I'll change behavior to follow its specifications.)

See also rust-lang/rust#64796 (comment), rust-lang/rust#64796 (comment), and rust-lang/rust#64796 (comment).

cc @jhpratt

@taiki-e
Copy link
Owner Author

taiki-e commented Sep 29, 2020

(IIRC) I didn't adopt this in #17 because most of the existing crates (e.g., rustversion) adopted the same behavior as the current one. (And if the user needs behavior that is different from the current behavior, could use const_fn(cfg(...)) + build script.)

@taiki-e
Copy link
Owner Author

taiki-e commented Mar 28, 2021

Stabilization report of cfg_version (rust-lang/rust#64796 (comment)) says:

version on the nightly channel

In the post-RFC discussion there has been a conversation about which version the nightly compiler should use as its supported version. Unlike beta or stable compilers, nightly compilers can still gain new features, and un-stabilizations are possible. So technically it's possible that newer code can rely on a feature that someone's pinned or not updated nightly does not support yet. On the other hand, during the stabilized-in-nightly phase, features often attain their largest extent of exposure before being shipped as part of a stable release.

The proposed compromise is to treat as a nightly's version as complete, but to add the -Z assume-incomplete-release flag added by rust-lang/rust#81468 . Users who pin their nightlies can enable it to back-date the supported version to the prior release. Intent is to keep it perma-unstable as it targets nightly users only. As this question only affects nightly compilers, the decision can also be revisited in the future.

@taiki-e
Copy link
Owner Author

taiki-e commented Mar 28, 2021

I want to provide API & behavior that matches cfg_version, so:

  • Assume that nightly is complete by default. This is the same as the current behavior.
  • If -Z assume-incomplete-release flag is specified, detect it from RUSTFLAGS by build script and assume that nightly is incomplete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant