-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.Blocker: Approved by a merged RFC but not yet implemented.B-RFC-implementedBlocker: Approved by a merged RFC and implemented but not stabilized.Blocker: Approved by a merged RFC and implemented but not stabilized.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCT-cargoRelevant to the cargo team, which will review and decide on the PR/issue.Relevant to the cargo team, which will review and decide on the PR/issue.
Description
This is a tracking issue for the RFC "Minimum Supported Rust Version" (rust-lang/rfcs#2495).
Note: There is a separate tracking issue on the Cargo side at: rust-lang/cargo#8072
Documentation: https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field
Steps:
- Implement the RFC (cc @rust-lang/cargo -- can anyone write up mentoring
instructions?)Adjust documentation (see instructions on rustc-guide)Stabilization PR (see instructions on rustc-guide)To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Unresolved questions:
- Name bike-shedding:
rust
vsrustc
vsmin-rust-version
- Additional checks?
- Better description of versions resolution algorithm.
- How nightly versions will work with "cfg based MSRV"?
demurgos, ogoffart, Keavon, duchainer, ldm0 and 3 morejyn514, Osspial, mark-i-m, hobofan, joshsleeper and 21 morejoshsleeper, raftario, jazeved0, archisgore, ShadowJonathan and 7 more
Metadata
Metadata
Assignees
Labels
B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.Blocker: Approved by a merged RFC but not yet implemented.B-RFC-implementedBlocker: Approved by a merged RFC and implemented but not stabilized.Blocker: Approved by a merged RFC and implemented but not stabilized.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCT-cargoRelevant to the cargo team, which will review and decide on the PR/issue.Relevant to the cargo team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
jhpratt commentedon Oct 10, 2019
My personal opinions:
Name →
min-rust-version
ormsrv
. The latter may have already been declined, but if accompanied by documentation it's certainly already relatively widespread.Nightly — Both the dated version (I no longer believe this is the best case. Using2019-10-10
) and the semver version (1.40.0
for when1.38.0
is stable). The latter could be somewhat confusing, as I've never seen nightly referred to like that in practice.2019-10-10
ornightly-2019-10-10
would be preferred.Majkl578 commentedon Oct 11, 2019
My personal preference would be
rust-version
.min-rust-version
is a bit too long andmsrv
is a bit cryptic abbreviation for newcomers (when I first saw it I was like what Microsoft stuff is this referring to).Regarding nightly versions: I do not like the suggestion by @jhpratt to use semver version for nightly (e.g.
1.40.0
) because the constraint is too wide. I think usingnightly-2019-10-10
(meaning nightly from 2019-10-10 or newer) would be better and specific enough.Cargo then needs to be able to resolve what real semver version this refers to and when e.g.
2019-10-10
means1.40.0
then stable1.41.0
would be valid too.mathstuf commentedon Oct 11, 2019
Agreed with @Majkl578 about the
nightly
via semver thing. Just becausenightly
has your feature today doesn't mean it will appear in the stable release with that version number.topokel commentedon Dec 9, 2019
I went through the discussions and I couldn't see anyone discussing representing the version as a semver version requirement like package dependencies, only instead defaulting to a
>= xxx
comparison operator when none is present instead of a caret operator. This would be useful personally, preserves the already proposed functionality, and seems like it'd reuse existing code. This leaves the nightly question open, however. Which perhaps would have to be a special case over all of that? 😅Lokathor commentedon Dec 9, 2019
Minimum rust version should absolutely be a semver comparison, yes.
topokel commentedon Dec 9, 2019
I read the RFC a second time and saw a part suggesting semver comparison but I'm leaving my comment to keep the use-case clearly vocalized
newpavlov commentedon Dec 9, 2019
What is this use-case though? In your previous post you only said it would be useful for you personally, without specifying why exactly. In the RFC I've wrote:
exactly because I didn't see why it would be useful outside of the nightly extension, and even with the extension I am not 100% sure this feature would pull its weight. Also IIRC during discussion no one have brought any substantial arguments for supporting range operators with "1.X" versions.
topokel commentedon Dec 9, 2019
Targeting a specific Rust ABI would require pinning the Rustc version to an exact number. This can easily be accomplished with semver without developing an entirely new syntax
84 remaining items
joshtriplett commentedon Sep 17, 2021
This is on track to be stabilized in 1.56.
newpavlov commentedon Sep 18, 2021
@joshtriplett
Great! What about the proposed MSRV-dependent dependency version resolution? Should we open a separate Rust or Cargo issue?
joshtriplett commentedon Sep 19, 2021
@newpavlov That was moved to future work because, among other things, it would need some confirmation that the proposed approach to resolution is something we'd want to do. Given such confirmation, someone would then need to submit a PR implementing it.
ehuss commentedon Sep 20, 2021
Sorry, forgot that there was a second tracking issue. Closing as this has been stabilized in rust-lang/cargo#9732.
newpavlov commentedon Sep 21, 2021
I went ahead and created a separate issue for MSRV-dependent dependency version resolution: #89136
Remove msrv 1.48 in favor of rust-version
rust-version
field inCargo.toml
to specify the MSRV rust-lang/rust-clippy#7765Specify the MSRV in the Cargo.toml
Merge #374
rust-version
to eachCargo.toml
build-trust/ockam#2204edition=2018
instead? microsoft/windows-rs#1699peter-lyons-kehl commentedon Nov 17, 2022
To save people's time: As per https://doc.rust-lang.org/nightly/cargo/reference/manifest.html#the-rust-version-field, the field is called
rust-version
.