Skip to content

Document interaction between custom profiles and overrides #13590

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

Closed
wants to merge 4 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions src/doc/src/reference/profiles.md
Original file line number Diff line number Diff line change
Expand Up @@ -369,6 +369,9 @@ The output for each profile will be placed in a directory of the same name
as the profile in the [`target` directory]. As in the example above, the
output would go into the `target/release-lto` directory.

NOTE: Custom profiles inherit package overrides as well and those take precedence
over the default custom profile settings. See the [overrides](#overrides) section for more.
Comment on lines +372 to +373
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about adding a sentence at line 250, instead of this?

- setting is not specified.
+ setting is not specified. Note that a custom profile inherits everything from
+ the other profile, including package and build [overrides](#overrides).


[`target` directory]: ../guide/build-cache.md

## Profile selection
Expand Down Expand Up @@ -457,6 +460,26 @@ match wins):

Overrides cannot specify the `panic`, `lto`, or `rpath` settings.

Overrides inherit to custom profiles and take precedence unless explicitly overriden.
For example, in the below example package `foo` will still be built with `opt-level = 1`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem to match the current behavior. Check this test as a reference:

fn overrides_with_custom() {
let p = project()
.file(
"Cargo.toml",
r#"
[package]
name = "foo"
version = "0.0.1"
edition = "2015"
authors = []
[dependencies]
xxx = {path = "xxx"}
yyy = {path = "yyy"}
[profile.dev]
codegen-units = 7
[profile.dev.package.xxx]
codegen-units = 5
[profile.dev.package.yyy]
codegen-units = 3
[profile.other]
inherits = "dev"
codegen-units = 2
[profile.other.package.yyy]
codegen-units = 6
"#,
)
.file("src/lib.rs", "")
.file("xxx/Cargo.toml", &basic_lib_manifest("xxx"))
.file("xxx/src/lib.rs", "")
.file("yyy/Cargo.toml", &basic_lib_manifest("yyy"))
.file("yyy/src/lib.rs", "")
.build();
// profile overrides are inherited between profiles using inherits and have a
// higher priority than profile options provided by custom profiles
p.cargo("build -v")
.with_stderr_unordered(
"\
[LOCKING] 3 packages
[COMPILING] xxx [..]
[COMPILING] yyy [..]
[COMPILING] foo [..]
[RUNNING] `rustc --crate-name xxx [..] -C codegen-units=5 [..]`
[RUNNING] `rustc --crate-name yyy [..] -C codegen-units=3 [..]`
[RUNNING] `rustc --crate-name foo [..] -C codegen-units=7 [..]`
[FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [..]
",
)
.run();
// This also verifies that the custom profile names appears in the finished line.
p.cargo("build --profile=other -v")
.with_stderr_unordered(
"\
[COMPILING] xxx [..]
[COMPILING] yyy [..]
[COMPILING] foo [..]
[RUNNING] `rustc --crate-name xxx [..] -C codegen-units=5 [..]`
[RUNNING] `rustc --crate-name yyy [..] -C codegen-units=6 [..]`
[RUNNING] `rustc --crate-name foo [..] -C codegen-units=2 [..]`
[FINISHED] `other` profile [unoptimized + debuginfo] target(s) in [..]
",
)
.run();
}

for profile `opt-dev`.

```
[profile.dev.package.foo]
opt-level = 2

[profile.opt-dev]
inherits = "dev"
opt-level = 1
```

If you wanted package `foo` to have an `opt-level` of `2`, you'd need to explicitly override
it for `opt-dev`:
```
[profile.opt-dev.package.foo]
opt-level = 2
```

### Overrides and generics

The location where generic code is instantiated will influence the
Expand Down