Tracking Issue for profile-rustflags

[ehuss]

Summary

Original issue: #7878
Implementation: #10217
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-rustflags-option

The profile-rustflags feature allows setting RUSTFLAGS per-profile.

Status update: #10271 (comment)

For per-target-profiles, see #4897

Unresolved Issues

• Are we ok with rustflags that can be set in Cargo.toml
• How should things interact with rustdoc? If there is a flag that is required to correctly build a project, then cargo test may fail if they aren't passed to rustdoc. However, rustdoc doesn't accept all of rustc's flags. Adding a rustdocflags option seems to be adding more unwanted complexity, though.
• This introduces potential backwards-compatibility hazards. For example, when Cargo adds new features or changes the way it invokes rustc, that can interfere with pre-existing flags. Is documenting this sufficient?
• What should the behavior be with build scripts and proc-macros? Those have historically been a pain point with rustflags. Perhaps there should be a default build-override.rustflags = [].
• Profile rustflags are not considered as part of TargetInfo, which impacts feature resolution and other things.

Future Extensions

No response

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

[bstrie]

I see something like this as necessary for the usability of RFC 3028 (artifact dependencies): #9096 . Historically Cargo has not supported passing arbitrary flags in profile overrides because many of them made no sense to pass to a dependency (e.g. -C linker). However, with binary artifacts, now literally all rustc flags become something that users will have valid reasons to want to specify. Currently this leads to lots of pain and workarounds with trying to use binary dependencies, either by hacking things up with Cargo config files (which don't work in all cases) or build scripts (which don't support all flags) or environment variables (which are difficult to set in all circumstances).

That doesn't mean that this feature is the only way to satisfy this need, but I think anything that does satisfy this need would have to be functionally equivalent to profile-rustflags.

[Qubasa]

cargo-features = ["per-package-target", "profile-rustflags"] don't work together.
By this I mean the target does not get applied when profile-rustflags get used.

cargo-features = ["per-package-target", "profile-rustflags"]

[package]
name = "perf_kernel"
version = "0.1.0"
authors = ["Luis Hebendanz <luis.nixos@gmail.com>"]
edition = "2021"
forced-target = "x86_64-unknown-none"

[profile.dev]
rustflags = [ "-C", "link-args=--image-base=0x200000" ]

Will fail with gcc: error: unrecognized command-line option '--image-base=0x200000' even though target defines ld.lld as linker

[MauriceKayser]

I can not get this to work with a no_std crate on Windows with the current nightly. Steps to reproduce the linker issue:

1. Create a new binary project.
2. Cargo.toml:

   [... default content ...]
   
   [profile.release]
   panic = "abort"

3. src/main.rs:

   #![no_main]
   #![no_std]
   
   #[panic_handler]
   fn rust_begin_unwind(_: &core::panic::PanicInfo) -> ! { loop {} }
   
   #[no_mangle]
   fn WinMainCRTStartup() -> u32 { 0 }

4. .cargo/config.toml:

   [target.'cfg(target_env = "msvc")']
   rustflags = [ "-C", "link-args=/Debug:None /SubSystem:Windows" ]

5. Compile with cargo build --release --target x86_64-pc-windows-msvc -Z build-std=core -> it succeeds.
6. Delete .cargo/config.toml.
7. Cargo.toml:

   cargo-features = [ "profile-rustflags" ]
   
   [... previous content ...]
   
   rustflags = [ "-C", "link-args=/Debug:None /SubSystem:Windows" ]

8. Compile with cargo build --release --target x86_64-pc-windows-msvc -Z build-std=core -> it succeeds.
9. Delete the target build artifact directory to enforce a complete recompilation.
10. Compile with cargo build --release --target x86_64-pc-windows-msvc -Z build-std=core -> it fails:

    Compiling compiler_builtins v0.1.85
    Compiling rustc-std-workspace-core v1.99.0
    
    error: linking with `link.exe` failed: exit code: 1120
    [... linker command arguments ...]
    note: msvcrt.lib(exe_winmain.obj) : error LNK2019: unresolved external symbol WinMain referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)
    build_script_build-[RandomHash].exe : fatal error LNK1120: 1 unresolved externals

It seems like it tries to link the things that should be excluded via no_std, like msvcrt and WinMain.
By the way, is it possible to use something like cfg(target_env = "msvc") with profile-rustflags?

[ehuss]

As mentioned in the unresolved section, profile rustflags get applied to build scripts. You can override that with:

[profile.dev.build-override]
rustflags = []

Also, I might suggest using the #[windows_subsystem] attribute instead of setting it manually.

Conditional settings are not supported in profiles, you'll need to use separate profiles.

In the future, please file a new issue if you have a question or problem. See the "About tracking issues" section above.

[MauriceKayser]

Sorry, I will read more carefully next time and create a separate issue instead. I did not realize that my example contained a build script, thanks for the hint! The #![windows_subsystem = "windows"] seems to be ignored, if applied to the example - it will look for mainCRTStartup, the console subsystem main function, instead of WinMainCRTStartup, the windows subsystem main function.