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

Cargo should tell build.rs what the Rust edition is #6408

Open
vandenoever opened this issue Dec 9, 2018 · 5 comments
Open

Cargo should tell build.rs what the Rust edition is #6408

vandenoever opened this issue Dec 9, 2018 · 5 comments
Labels
A-build-scripts Area: build.rs scripts A-editions Area: edition-specific issues C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@vandenoever
Copy link

Describe the problem you are trying to solve
Syntax between Rust 2015 and Rust 2018 is different. Generating code in build.rs should know what edition of Rust to generate code for.
The code could parse Cargo.toml to figure this out, but it's cumbersome.

Describe the solution you'd like
An environment variable e.g. RUST_EDITION=2018 would help.

@alexcrichton alexcrichton added A-build-scripts Area: build.rs scripts C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` labels Dec 10, 2018
@ehuss
Copy link
Contributor

ehuss commented Dec 18, 2018

This may be complicated by the fact that targets within a package can be in different editions. I imagine just including the package edition would cover 99.9% of the situations, but there should be at least a note in the documentation about this potential pitfall.

@ehuss
Copy link
Contributor

ehuss commented Dec 18, 2018

@ehuss ehuss added the A-editions Area: edition-specific issues label Apr 6, 2020
@epage epage added the S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. label Oct 25, 2023
@epage
Copy link
Contributor

epage commented Oct 25, 2023

This may be complicated by the fact that targets within a package can be in different editions.

I had to go look at the docs because I found this so surprising.

@nyurik
Copy link
Contributor

nyurik commented Nov 30, 2024

Turns out I rushed to implementation with #14873 when this feature hasn't been settled yet... I do think we should simply provide the root-level edition, even if edition can be set on each target (why is it even possible is beyond me). And I do agree that in theory compiler may want to allow per-mod edition too, allowing auto-generated code to use an older edition than the overall package.

@epage
Copy link
Contributor

epage commented Dec 2, 2024

My concern with CARGO_PKG_EDITION is for people creating build script libraries. It looks like the tool for the job and but it could fail at that job. It feels like a misleading promise from the Cargo to provide it. For me, I think I'd only consider it if we were to deprecate per-target editions and remove them in a future edition. I think the reason per-target editions exist is to allow more gradual migration. There is also a small chance of someone wanting to provide edition-specific examples but that seems unlikely. In considering targets vs packages, I lean towards packages.

There would be other areas that could potentially benefit from per-mod or per-block editions, like with doctests which are allowed to be per-edition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-build-scripts Area: build.rs scripts A-editions Area: edition-specific issues C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

5 participants