fix(host-config): dont apply target config to host artifacts by weihanglo · Pull Request #17123 · rust-lang/cargo

weihanglo · 2026-06-20T05:59:23Z

What does this PR try to resolve?

With -Zhost-config,
a host artifact must only take its config from [host]
but never from [target.'cfg(...)'].

The bug is that the first branch of target_{linker,runner}
already routes [host] and [target] correctly.
However, later the cfg fallback read the global target_cfgs()
so a host artifact wrongly picked up the target's cfg() linker.

This patch follows the same pattern extra_args has used.

How to test and review this PR?

Two regression tests are added.

Fixes rust-lang/miri#5101

To test against the repro https://github.com/nazar-pc/miri-5101-reproduction, run

RUSTFLAGS="-Znext-solver=globally" MIRIFLAGS="-Znext-solver=globally" \
  rustup run nightly /path/to/pr17123/cargo miri test \
  -Ztarget-applies-to-host -Zhost-config \
  --config 'host.rustflags=["-Znext-solver=globally"]' --lib

See rust-lang/miri#5101 (comment)

With `-Zhost-config`, a host artifact must only take its config from `[host]` but never from `[target.'cfg(...)']`. The first branch of `target_runner` already routes `[host]` and `[target]` correctly. However, later the cfg fallback read the global `target_cfgs()` so a build script wrongly picked up the target's `cfg()` runner. This patch follows the same pattern `extra_args` has used.

See rust-lang/miri#5101 (comment)

With `-Zhost-config`, a host artifact must only take its config from `[host]` but never from `[target.'cfg(...)']`. The first branch of `target_linker` already routes `[host]` and `[target]` correctly. However, later the cfg fallback read the global `target_cfgs()` so a host artifact wrongly picked up the target's `cfg()` linker. This patch follows the same pattern `extra_args` has used.

rustbot · 2026-06-20T05:59:28Z

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @ehuss, @epage, @weihanglo
@ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
Random selection from ehuss, epage

Update cargo submodule 9 commits in 598ab48ec328e3e4f5e4e373d8df7264bc8e27cd..a595d0da21f228b7fdae64d3d5c0e527ea66bb59 2026-06-17 02:39:50 +0000 to 2026-06-20 13:42:59 +0000 - fix(host-config): dont apply target config to host artifacts (rust-lang/cargo#17123) - chore(deps): update msrv to v1.94 (rust-lang/cargo#17121) - test(update): show cross-registry multi-spec precise (rust-lang/cargo#17119) - fix(resolver): hint how to resolve too-new versions (rust-lang/cargo#17118) - fix(add): list too-new versions and how to override (rust-lang/cargo#17117) - feat: `-Zmin-publish-age` (RFC 3923) (rust-lang/cargo#17012) - feat(diag): Support `build.warnings` for cargo lints (rust-lang/cargo#17112) - Remove windows-sys dependencies older than 0.61 (rust-lang/cargo#17115) - fix(install): Run cargo lints like rustc lints (rust-lang/cargo#17107)

Captured behaviors are likely bugs introduced by rust-lang#17123 See also rust-lang/miri#5101

rust-lang#17123 made host artifacts stop picking up `target.'cfg(..)'.runner` and `target.'cfg(..)'.linker` even without `-Ztarget-applies-to-host -Zhost-config`. That silently changed stable behavior that `target.'cfg(..)'` no longer applied to proc-macro and build script compilation under `--target <host>`, while `target.<triple>` config still did. The old gate reused `host_artifact_uses_only_host_config`, which is for the documented rustflags dual behavior. It wasn't for runner and linker. This PR narrows the gate to `target-applies-to-host = false` and restore to pre PR 17123 stable behavior, while keeping `-Zhost-config` fix as it is still nightly.

Captured behaviors are likely bugs introduced by rust-lang#17123 See also rust-lang/miri#5101

rust-lang#17123 made host artifacts stop picking up `target.'cfg(..)'.runner` and `target.'cfg(..)'.linker` even without `-Ztarget-applies-to-host -Zhost-config`. That silently changed stable behavior that `target.'cfg(..)'` no longer applied to proc-macro and build script compilation under `--target <host>`, while `target.<triple>` config still did. The old gate reused `host_artifact_uses_only_host_config`, which is for the documented rustflags dual behavior. It wasn't for runner and linker. This PR narrows the gate to `target-applies-to-host = false` and restore to pre PR 17123 stable behavior, while keeping `-Zhost-config` fix as it is still nightly.

### What does this PR try to resolve? Related: rust-lang#17200 rust-lang#17123 made host artifacts stop picking up `target.cfg(…).runner` and `target.cfg(…).linker` even without `-Zhost-config`. That silently changed stable behavior that `target.cfg` no longer applied to proc-macro and build script compilation under `--target <host>`, while `target.<triple>` config still did. The old gate reused `host_artifact_uses_only_host_config`, which is for the documented rustflags dual behavior. It wasn't for runner and linker. This PR narrows the gate to `target-applies-to-host = false` and restore to pre-rust-lang#17123 stable behavior, while keeping `-Zhost-config` fix as it is still nightly. ### How to test and review this PR? I've added a lot of tests because I don't want to miss any edge cases again. Here is the change table. | test | 1.97 | 1.98-beta (rust-lang#17123) | this PR (rust-lang#17198) | |---|---|---|---| | `custom_runner_cfg_proc_macro_test_with_target` | applies | not | _applies_ | | `target_cfg_linker_build_script_with_target` | applies | not | _applies_ | | `target_cfg_linker_proc_macro_with_target` | applies | not | _applies_ | | `target_cfg_linker_proc_macro_test_with_target` | applies | not | _applies_ | | `target_cfg_runner_build_script_with_host_config_and_target` | applies | not | not | | `target_cfg_linker_build_script_with_host_config_and_target` | applies | not | not | All other added tests behave identically across 1.97, 1.98-beta, and this PR. See rust-lang#17200 for the runner/linker inconsistency they document. ### Note We'll need to backport this to 1.98-beta once it lands.

Captured behaviors are likely bugs introduced by #17123 See also rust-lang/miri#5101

#17123 made host artifacts stop picking up `target.'cfg(..)'.runner` and `target.'cfg(..)'.linker` even without `-Ztarget-applies-to-host -Zhost-config`. That silently changed stable behavior that `target.'cfg(..)'` no longer applied to proc-macro and build script compilation under `--target <host>`, while `target.<triple>` config still did. The old gate reused `host_artifact_uses_only_host_config`, which is for the documented rustflags dual behavior. It wasn't for runner and linker. This PR narrows the gate to `target-applies-to-host = false` and restore to pre PR 17123 stable behavior, while keeping `-Zhost-config` fix as it is still nightly.

weihanglo added 5 commits June 20, 2026 01:56

refactor: extract host-only config predicate

923d6eb

test(host-config): show target runner got picked up wrongly

9306ead

See rust-lang/miri#5101 (comment)

test(host-config): show target linker got picked up wrongly

ec71989

See rust-lang/miri#5101 (comment)

rustbot assigned epage Jun 20, 2026

rustbot added A-build-execution Area: anything dealing with executing the compiler A-cfg-expr Area: Platform cfg expressions S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 20, 2026

weihanglo mentioned this pull request Jun 20, 2026

-Zhost-config breaks cargo miri test on proc macros under Miri rust-lang/miri#5101

Closed

epage approved these changes Jun 20, 2026

View reviewed changes

epage added this pull request to the merge queue Jun 20, 2026

weihanglo mentioned this pull request Jun 20, 2026

Update cargo submodule rust-lang/rust#158164

Merged

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jun 20, 2026

ehuss added this pull request to the merge queue Jun 20, 2026

Merged via the queue into rust-lang:master with commit a595d0d Jun 20, 2026
29 checks passed

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 20, 2026

This was referenced Jun 20, 2026

Support miriflags in [target] configuration #17079

Open

fix: cargo tree artifact target feature keys #17124

Draft

rustbot added this to the 1.98.0 milestone Jun 20, 2026

nazar-pc mentioned this pull request Jun 21, 2026

Miri errors when trying to run tests on proc macro rust-lang/miri#5122

Closed

weihanglo deleted the host-config-fix branch June 22, 2026 14:45

weihanglo added a commit to weihanglo/cargo that referenced this pull request Jul 11, 2026

test: capture runner selection for host artifacts

b96f9f4

Captured behaviors are likely bugs introduced by rust-lang#17123 See also rust-lang/miri#5101

weihanglo added a commit to weihanglo/cargo that referenced this pull request Jul 11, 2026

test: capture runner selection for host artifacts

bb5a1df

Captured behaviors are likely bugs introduced by rust-lang#17123 See also rust-lang/miri#5101

weihanglo mentioned this pull request Jul 11, 2026

fix: dont apply host-config gating to stable behavior #17198

Merged

weihanglo mentioned this pull request Jul 11, 2026

Inconsistency of proc-macro tests using target runners #17200

Open

epage pushed a commit that referenced this pull request Jul 14, 2026

test: capture runner selection for host artifacts

9582e30

Captured behaviors are likely bugs introduced by #17123 See also rust-lang/miri#5101

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(host-config): dont apply target config to host artifacts #17123

fix(host-config): dont apply target config to host artifacts #17123
ehuss merged 5 commits into
rust-lang:masterfrom
weihanglo:host-config-fix

weihanglo commented Jun 20, 2026 •

edited

Loading

Uh oh!

rustbot commented Jun 20, 2026

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

weihanglo commented Jun 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR try to resolve?

How to test and review this PR?

Uh oh!

rustbot commented Jun 20, 2026

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

weihanglo commented Jun 20, 2026 •

edited

Loading