cargo: Use --env-set when we have nightly rustc

[xclaesse]

No description provided.

[xclaesse]

From #15138 (comment)

I would also move env_set to a separate PR, and add a rustc_nightly feature option to opt into it (enabled = require nightly, disabled = never use nightly features which would be the default). I think most projects would want to compile the same code for nightly and non-nightly.

I don't think we need an option because it is already the user who opt-in by selecting the nightly rustc with rustup default nightly. Until --env-set gets stabilized (rust-lang/rust#119926) most crates will fail to build without nightly. I've been hesitant to make nightly required, or warn if it's not nightly, but the problem is we don't know when it's going to be stabilized so we'll keep warning even when rustc has it stabilized.

[bonzini]

I don't think we need an option because it is already the user who opt-in by selecting the nightly rustc with rustup default nightly.

But developers who use nightly as a default on their machine (if only because half of rustfmt's options are nightly-only, or to run against latest clippy warnings) might not want to enable random nightly features.

I don't think it's true that "most" crates fail without nightly due to env!. It's something that we'll have to deal with sooner or later, but it's fairly down the priority list. If any high-profile crate needs it, we can cover it with wrapdb support, similar to what has to be done for build.rs. I have tried all of librsvg's dependencies, and the current Cargo interpreter (with fixed feature resolution) builds over 230 crates without doing anything about environment or even build.rs.

In fact, the common case is OUT_DIR, which needs manual work to convert build.rs to ninja-time custom_targets anyway, and also opens Pandora's box of [build-dependencies].

[bonzini]

Fixes: #13752

[xclaesse]

But developers who use nightly as a default on their machine (if only because half of rustfmt's options are nightly-only, or to run against latest clippy warnings) might not want to enable random nightly features.

Not random, it's now only enabled for AST generated by cargo subprojects for --set-env. Does it have other effect than allowing extra CLI arguments?

But developers who use nightly as a default on their machine (if only because half of rustfmt's options are nightly-only, or to run against latest clippy warnings) might not want to enable random nightly features.

I guess it depends what set of crates you're using. I've been trying with the list from gst-plugins-rs, and OUT_DIR is a really common usage.

In fact, the common case is OUT_DIR, which needs manual work to convert build.rs to ninja-time custom_targets anyway, and also opens Pandora's box of [build-dependencies].

As long as there are no build-dependencies, the build.rs can easily be run by Meson. I have a branch doing that. For example serde has a build.rs that generate OUT_DIR/private.rs and using --env-set OUT_DIR makes it work out of the box.

[bonzini]

For example serde has a build.rs that generate OUT_DIR/private.rs and using --env-set OUT_DIR makes it work out of the box.

There are several cases, and there are very few that both work and matter

• the serde one you mention (also used by IIRC thiserror) is a hack - it can be handled via diff files as well, and it's not really worth requiring nightly

• a nice and useful one, that can be handled automatically, is serde_json which looks at the target architecture. But more often you'll see usage of crates like autocfg, rustc_versionorversion_check`. Overall, this kind of use is very easy to be converted to meson/meson.build, and often (as a first approximation) can be left out at some performance cost.

• code generation is the complex one, as that would have to run at ninja time instead. In librsvg the two remaining cases are phf-codegen and string_cache_codegen, neither of which can be handled easily. They would require some heavy meson/meson.build work.

It would be possible to add opt-in build.rs handling, with something like meson/meson.build doing extra_args += import('rust').build_rs_args(files('build.rs'))`. But I'm not sure is worth it.

But I'd rather try something like a meson_env crate, providing a procedural macro that is a drop-in for env! and can be patched via diff-files as well. Create them as INI or TOML files in meson-private, and read them from the procedural macro.

[bonzini]

To be clear, I still think we should commit something like this patch. And we should be using nightly when it makes sense, e.g. for rust_dynamic_std with staticlibs. But at the same time, use of nightly features should be strictly opt-in.

[xclaesse]

@bonzini what I don't understand is what downside does it have to use nightly features when available? It just make more things work out of the box. That limit the amount of projects that will require patching. I also do that to showcase that they really should stabilize --env-set.

Maybe it should be a global rust compiler option? i.e. -Drust_nightly=enabled?

[bonzini]

Maybe it should be a global rust compiler option? i.e. -Drust_nightly=enabled?

That's exactly what I said above. :)) maybe we disagree on the default but having the option would make it a simple poll.

[xclaesse]

That's exactly what I said above. :))

Ok, misunderstood, I thought you meant rust module option.

maybe we disagree on the default but having the option would make it a simple poll.

I made it auto by default, meaning it uses nightly features if available. Setting it to enabled will abort if it's a stable rustc. Setting it to disabled will prevent using --env-set, and potentially other features in the future.

[dcbaker]

I wonder if this is the way forward with some of these changes we would like from Rust in general. The "Look, a downstream is using this successfully to solve their problems" argument is more convincing than "We think we can solve our problems with this feature".

[xclaesse]

I changed OUT_DIR to be <buiddir>/meson, that way meson/meson.build can use configure_file() and they'll be usable by crates, just like build.rs does.