Skip to content

Tracking Issue for profile-rustflags #10271

New issue
New issue
Open
Open
Tracking Issue for profile-rustflags#10271
Labels
A-profilesArea: profilesA-rustflagsArea: rustflagsC-tracking-issueCategory: A tracking issue for something unstable.S-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.S-waiting-on-feedbackStatus: An implemented feature is waiting on community feedback for bugs or design concerns.Z-profile-rustflagsNightly: profile-rustflags

Description

@ehuss
ehuss
opened on Jan 7, 2022

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.

Activity

  1. Imageehuss
    added
    A-profilesArea: profiles
    C-tracking-issueCategory: A tracking issue for something unstable.
    A-rustflagsArea: rustflags
    on Jan 7, 2022

  2. bstrie commented on Apr 29, 2022

    @bstrie
    bstrie
    on Apr 29, 2022
    Contributor

    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.

  3. Qubasa commented on Sep 29, 2022

    @Qubasa
    Qubasa
    on Sep 29, 2022

    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

  4. Imageehuss
    added
    Z-profile-rustflagsNightly: profile-rustflags
    on Dec 11, 2022

  5. MauriceKayser commented on Jan 28, 2023

    @MauriceKayser
    MauriceKayser
    on Jan 28, 2023 · Hidden as off-topic

  6. ehuss commented on Jan 28, 2023

    @ehuss
    ehuss
    on Jan 28, 2023 · Hidden as off-topic
    Author

  7. MauriceKayser commented on Jan 29, 2023

    @MauriceKayser
    MauriceKayser
    on Jan 29, 2023 · Hidden as off-topic
  8. Imageehuss
    added
    S-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
    S-waiting-on-feedbackStatus: An implemented feature is waiting on community feedback for bugs or design concerns.
    S-needs-mentorStatus: Issue or feature is accepted, but needs a team member to commit to helping and reviewing.
    on Apr 25, 2023
  9. Imageepage
    added this to Cargo Roadmapon Sep 5, 2023
  10. Imageepage
    moved this to Unstable, baking in Cargo Roadmapon Sep 5, 2023

  11. nuzzles commented on Dec 5, 2023

    @nuzzles
    nuzzles
    on Dec 5, 2023 · Hidden as resolved

  12. 15 remaining items

  13. RalfJung commented on Aug 10, 2024

    @RalfJung
    RalfJung
    on Aug 10, 2024 via email
    Member

  14. JohnstonJ commented on Oct 5, 2024

    @JohnstonJ
    JohnstonJ
    on Oct 5, 2024 · Hidden as off-topic

  15. weihanglo commented on Oct 5, 2024

    @weihanglo
    weihanglo
    on Oct 5, 2024 · Hidden as off-topic

  16. BatmanAoD commented on Oct 8, 2024

    @BatmanAoD
    BatmanAoD
    on Oct 8, 2024
    Contributor

    It appears to me that this permits Cargo users to expose themselves to potential soundness issues to which they were previously immune. There's a discussion here about it, but the short version is that when the user has control over per-package Rust-flags, they can choose to compile some packages with panic=abort and others with panic=unwind. So far, I think that's still safe, because rustc itself will refuse to link the panic=unwind runtime if any crates in the dependency graph were compiled with panic=abort (unless the relevant part of RFC 1513 is no longer correct). But even if the panic=abort runtime is linked, it's still possible to run into UB by calling functions in other languages that unwind.

    If my understanding is correct, there should be a prominent warning in the documentation for this feature that by changing the compilation flags for individual crates, the user loses some of the protections typically afforded to Cargo users.

    Additionally, when this feature is stabilized, the "note" in the "Prohibited Linkage Scenarios" section of the reference (not merged yet) should be changed to acknowledge that this feature enables bypassing Cargo's protection against this particular UB:

    Note: by default, Cargo compiles all crates in a dependency graph with the same panic runtime, and then links the final binary against the same panic runtime. This ensures that it is safe to have dependencies that specify a different panic runtime than the one ultimately used by your project, because the dependency crate's selected panic runtime will be ignored. However, it is possible to manually specify compile flags for individual packages using a [profile][cargo-profiles] that includes package.<name>.rustflags; this makes it possible to bypass any such protection Cargo might be able to provide.

  17. RalfJung commented on Oct 8, 2024

    @RalfJung
    RalfJung
    on Oct 8, 2024
    Member

    Generally the expectation is that rustc must ensure that the crates it is linking are actually compatible for linking. So if this cargo feature can be used to cause unsoundness, that sounds like a soundness bug in rustc to me.

  18. BatmanAoD commented on Oct 8, 2024

    @BatmanAoD
    BatmanAoD
    on Oct 8, 2024
    Contributor

    It's not just this feature, though: it's this feature, in conjunction with an FFI call to another language that then starts an unwind operation. rustc can't detect all the conditions required to cause UB here, which is why we created a lint, ffi_unwind_calls, to help users avoid it.

    Edit: I think I was mistaken; rustc should simply refuse to linked in this case, not produce a binary with UB. rust-lang/rust#97235

  19. loynoir commented on Apr 15, 2025

    @loynoir
    loynoir
    on Apr 15, 2025 · Hidden as duplicate

  20. weihanglo commented on Apr 15, 2025

    @weihanglo
    weihanglo
    on Apr 15, 2025 · Hidden as duplicate

  21. epage commented on Sep 5, 2025

    @epage
    epage
    on Sep 5, 2025
    Contributor

    We discussed this briefly in a cargo team meeting on 2025-05-20 and the impression I had is that the following unresolved question is the biggest blocker for stabilizing this feature:

    Are we ok with rustflags that can be set in Cargo.toml

    [profile] is present in both .cargo/config.toml and Cargo.toml and afaik we don't specialize some settings to only work in one or the other. This means within our current approach to things, to have this feature for .cargo/config.toml, we'd have to have it also in Cargo.toml.

    The problem with it in Cargo.toml is a matter of layer of abstractions:

    low level high level
    compiling cargo rustc cargo build
    customizing compilation rustflags profile
    custom conditional compilation cfg features (and maybe more)

    The lower level abstractions are more raw where you can hold it wrong, be broken by changes in cargo, could be platform specific, or even be environment specific. Config works well for these because it is low level, out of the users face, and dependent on the environment you are running in and overrideable.

    Manifests are part of the primary UX of cargo and, like the basic commands, it is more approachable and offers more guard rails around your actions.

  22. kornelski commented on Sep 6, 2025

    @kornelski
    kornelski
    on Sep 6, 2025
    Contributor

    Although I'd like having more control over build settings per profile, I don't think rustflags is the right mechanism for it.

    It's too broad and powerful. When it's treated as an opaque list of options, while also being merged with rustflags from other sources and Cargo's own flags, it's too easy to end up with conflicting flags.

    rustflags can be target-specific and break cross-compilation when applied unconditionally. Supporting per-profile rustflags without also supporting per-profile-per-target rustflags could force users to choose between supporting profiles and supporting cross-compilation.

    Linker flags meant for a particular binary don't belong in [profile] anyway. The same profile could end up being applied to build scripts, proc macros and other binaries that may not need the same linker flags (it will be even more problematic when Cargo starts supporting bin artifacts or dylib Rust dependencies and the linker flags meant for the top-level crate only end up getting applied to random crates in the dependency tree). A better place for linker flags would be in [lib], [[bin]], [[example]], etc.

    So instead I'd prefer Cargo to fast-track adding Cargo-native options for the features that users currently need rustflags for: #12739 #5881

  23. Imageepage
    removed
    S-needs-mentorStatus: Issue or feature is accepted, but needs a team member to commit to helping and reviewing.
    on Jan 22, 2026
  24. Imagerefcell
    added a commit that references this issue on Mar 21, 2026

    ktlo(workspace): stabilize profile.rustflags in profiling profile

    5719e73
  25. Imagejtmoon79
    added a commit that references this issue on Apr 5, 2026

    (PROJECT) NFC TODO use rustflags when stable

    9d3bee5
  26. Imagejacovdbergh
    added a commit that references this issue on Apr 19, 2026

    CI: override target-cpu=native via --config to fix clippy SIGILL

    e5afce4
  27. Imageermo
    added a commit that references this issue on Oct 29, 2026

    Cargo.toml: Remove line-tables-only for development builds

    7835c3a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-profilesArea: profilesA-rustflagsArea: rustflagsC-tracking-issueCategory: A tracking issue for something unstable.S-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.S-waiting-on-feedbackStatus: An implemented feature is waiting on community feedback for bugs or design concerns.Z-profile-rustflagsNightly: profile-rustflags

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions