Add new `misleading_cfg_in_build_script` lint by GuillaumeGomez · Pull Request #153721 · rust-lang/rust

GuillaumeGomez · 2026-03-11T14:15:49Z

Fixes #125441.
Fixes rust-lang/rust-clippy#9419.

Take-over of rust-lang/rust-clippy#12862.

It was originally implemented in clippy but the clippy thought it made for sense for such a lint to be directly implemented in rustc. I applied all suggestions made on the original PR and also improved the code overall (added docs too).

So on a build.rs from cargo crate, we will check for any target_*, unix and windows cfg and warn about them.

Since you made the original review on clippy.

r? @Urgau

rustbot · 2026-03-11T14:15:53Z

Some changes occurred in check-cfg diagnostics

cc @Urgau

GuillaumeGomez · 2026-03-11T14:35:29Z

Added a ui test to ensure this lint is only emitted on cargo build.rs scripts.

Urgau · 2026-03-11T18:06:22Z

compiler/rustc_lint/src/misleading_cfg_in_build_script.rs

+fn is_build_script(cx: &EarlyContext<'_>) -> bool {
+    rustc_session::utils::was_invoked_from_cargo()
+        && cx.sess().opts.crate_name.as_deref() == Some("build_script_build")
+}


This seems quite hacky and brittle for a lint.

Is there a better to detect if we are compiling a Cargo build script? If there isn't, we could maybe consider having the lint allowed by-default, but have Cargo implicitly set it to warn for build-scripts.

cc @rust-lang/cargo

Agreed, not great. :-/

I was kinda hoping that we had a "build script" crate kind but we don't (which is logical but still, not fun).

Just put it in t-cargo meeting agenda :)
next meeting time: Tue, Mar 17, 2026, 10:00 UTC-4

https://hackmd.io/-vJMV3isQfqu2d2J91t1eA

GuillaumeGomez · 2026-03-12T13:21:44Z

CI is finally happy. ^^'

ehuss · 2026-03-17T16:24:55Z

The cargo team discussed this today (notes). Some comments from that discussion:

We were largely OK with the approach of making this allow-by-default and having cargo set it to a warning when building a build script.
I was concerned about the possible amount of false-positives this would generate. Has there been a crater run or other analysis of what kind of false-positives this might hit? For example, if some build script has "cfg(windows) ... run executable that only exists on windows", it seems like this would be a false positive.
I assume this would need lang-team approval. It might be good to get this on their radar.
As an outsider looking at the diff, I am rather surprised to see yet another cfg parser being implemented here. I'm curious why this isn't using the standard cfg parser?

GuillaumeGomez · 2026-03-17T16:33:49Z

Sounds good.
It's a valid concern, to which I don't really have an answer to. Only answer is to run a crater run to see the impact it would have.
We're not clear which team is "in charge" here.
Unless I missed something, the cfg parser requires data I don't have? I'd love to be proven wrong though, would reduce the code quite a lot!

Urgau · 2026-03-17T18:26:14Z

I assume this would need lang-team approval. It might be good to get this on their radar.

I would expect a T-cargo FCP, with maybe T-compiler, but not T-lang. The lint proposed here has nothing to do with the language, it's purely a compiler and Cargo affair.

To elaborate a bit more, this lint could be in cargo it-self if we had a custom linting system, and it wouldn't need T-lang approval for that, so I don't think it needs one. We also (T-compiler) didn't ask T-lang to FCP the #[cfg]/--cfg lints.

As an outsider looking at the diff, I am rather surprised to see yet another cfg parser being implemented here. I'm curious why this isn't using the standard cfg parser?

I wouldn't look to closely at the impl. I haven't yet done a review of it, I wanted to wait for T-cargo input first.

Urgau

I share the concerns from Eric, about having another cfg parser.

Fortunately, this lint is simple enough that it can use the same infra as the unexpected_cfgs lint and perform the verification directly when parsing the cfgs them-selves in rustc_attr_parsing.

This will require some code re-shuffling between different crates (rustc_attr_parsing, rustc_lint_defs, rustc_lint, ...). You can follow what has been done for the UNEXPECTED_CFGS lint.

View changes since this review

Urgau · 2026-03-18T17:31:00Z

compiler/rustc_lint/src/misleading_cfg_in_build_script.rs

+declare_lint! {
+    /// Checks for usage of `#[cfg]`/`#[cfg_attr]`/`cfg!()` in `build.rs` scripts.
+    ///
+    /// ### Explanation
+    ///
+    /// It checks the `cfg` values for the *host*, not the target. For example, `cfg!(windows)` is
+    /// true when compiling on Windows, so it will give the wrong answer if you are cross compiling.
+    /// This is because build scripts run on the machine performing compilation, rather than on the
+    /// target.
+    ///
+    /// ### Example
+    ///
+    /// ```rust,ignore (can only be run in cargo build scripts)
+    /// if cfg!(windows) {}
+    /// ```
+    ///
+    /// Use instead:
+    ///
+    /// ```rust
+    /// if std::env::var("CARGO_CFG_WINDOWS").is_ok() {}
+    /// ```
+    pub MISLEADING_CFG_IN_BUILD_SCRIPT,
+    Warn,
+    "use of host configs in `build.rs` scripts"
+}


To be moved to rustc_lint_defs.

Most lints are defined directly in their file in this crate, so I'll keep the same logic.

Urgau · 2026-03-18T17:32:58Z

compiler/rustc_lint/src/misleading_cfg_in_build_script.rs

+fn get_invalid_cfg_attrs(attr: &MetaItem, spans: &mut Vec<Span>, has_unknown: &mut bool) {
+    let Some(ident) = attr.ident() else { return };
+    if [sym::unix, sym::windows].contains(&ident.name) {
+        spans.push(attr.span);
+    } else if attr.value_str().is_some() && ident.name.as_str().starts_with("target_") {
+        spans.push(attr.span);
+    } else if let Some(sub_attrs) = attr.meta_item_list() {
+        for sub_attr in sub_attrs {
+            if let Some(meta) = sub_attr.meta_item() {
+                get_invalid_cfg_attrs(meta, spans, has_unknown);
+            }
+        }
+    } else {
+        *has_unknown = true;
+    }
+}


To be moved in parse_name_value:

rust/compiler/rustc_attr_parsing/src/attributes/cfg.rs

Line 175 in 53d60bb

pub(crate) fn parse_name_value<S: Stage>(

Urgau · 2026-03-18T17:34:16Z

compiler/rustc_lint/src/misleading_cfg_in_build_script.rs

+        if !is_build_script(cx) {
+            return;
+        }


To be removed since T-cargo is onboard with enabling the lint for build scripts on their side.

Suggested change

if !is_build_script(cx) {

return;

}

ehuss · 2026-03-23T23:03:50Z

I would expect a T-cargo FCP, with maybe T-compiler, but not T-lang. The lint proposed here has nothing to do with the language, it's purely a compiler and Cargo affair.

I don't think that's how lints have been handled in the past. They all need to be approved by the lang team. I'm not aware of any exclusions.

GuillaumeGomez · 2026-03-23T23:05:29Z

I'm surprised: I added lints in the past without needing t-lang approval (although it might have been a few years for the last one... ^^').

nikomatsakis · 2026-04-01T15:00:51Z

👋 Just wanted to weigh in wearing lang hat--

I agree that lang's buy-in is not required for every lint, I feel that lang decides on lints that pertain to how people use the language but lints and warnings specific to the compiler seem out of scope. Sometimes there's a bit of ambiguity, a cc is always appreciated.
I don't understand @GuillaumeGomez why you removed the labels. They're used to auto-generate agendas and (as everyone seems to agree) do not represent a need to block. My read of your comment is that you're frustrated with having had to discuss this at all, which I get, but don't take it out on the bots man!

traviscross · 2026-04-01T15:01:04Z

Feel free to discuss it with the team if you want to provide feedback or preferences...

These tags put it on the agenda so it can be discussed with the team. That's all.

GuillaumeGomez · 2026-04-01T15:03:30Z

2. I don't understand @GuillaumeGomez why you removed the labels. They're used to auto-generate agendas and (as everyone seems to agree) do not represent a need to block. My read of your comment is that you're frustrated with having had to discuss this at all, which I get, but don't take it out on the bots man!

Not very nice to call traviscross a bot. 😝

These tags put it on the agenda so it can be discussed with the team. That's all.

Noted, my bad. Please add them back then.

Mark-Simulacrum · 2026-04-01T15:38:43Z

Is there a reason this can't be implemented via the existing check-cfg checks? Do we not support opting out of permitting built-in cfgs via check-cfg? If it can be done via check-cfg, is the reason this is a new lint just for better error messages (since we can guide the user about the build script specific context)?

GuillaumeGomez · 2026-04-01T15:43:09Z

I'm supposed to rewrite a big part of this lint to reuse existing cfg attribute parsing. Also the problem here is that we need to check all cfgs, including the ones that get removed early on and the cfg! macro. For that to work, we need to run before the expansion pass.

nikomatsakis · 2026-04-01T17:19:04Z

This was discussed in the lang-team call today. The consensus on the call was as follows:

We are happy to have compiler/cargo drive decisions on this lint, as the thread already concluded.
We don't agree that this is outside lang scope -- this seems to fall within the purview of a lang lint (i.e., it impacts which language features are used and how).
But we don't think it's only lang scope. This is very tooling focused (i.e., it is tied to the workflows of cargo + compiler and the specifics of how a build.rs program is compiled) and hence it feels also compiler/cargo scope.

As usual, if multiple teams have purview, we could have all of them on the FCP, but that's pretty tedious. We think it's simpler overall for us to leave the final decision to y'all, as we did on RFC 3013.

One last thing -- we've noticed that these kind of issues that lie at the intersection of multiple teams have been a source of friction lately. Might be a good thing to talk about at the All Hands.

traviscross · 2026-04-01T19:03:03Z

In the meeting, @nikomatsakis asked whether, setting aside jurisdictional questions, any of us had concerns about this lint. Nothing came to mind in the meeting. But looking at the situation afterward, I have some questions. Looking around GitHub briefly, these uses stood out to me as valid:

Project	File	Pattern	What it does
mullvad/mullvadvpn-app	`build.rs`	`cfg!(target_os = ...)` in `host_os()`, `CARGO_CFG_*` in `target_os()`	Deliberately uses both; compares host and target to decide whether to build a DLL.
denoland/rusty_v8	`build.rs`	`cfg!(target_os = "macos") && cfg!(target_arch = "aarch64")`	Documents the host/target distinction in a comment, then uses `cfg!` for host detection to fix GN's `host_cpu`.
webbeef/webviewer	`build.rs`	`CARGO_CFG_TARGET_OS` for target, `#[cfg(windows)]` for host	Checks target OS first, then gates `winres` on host being Windows, with an explicit cross-compilation panic.
agersant/polaris	`build.rs`	`#[cfg(windows)]` / `#[cfg(unix)]`	Embeds a Windows icon via `winres` — a host tool that only works on Windows.
tokio-rs/prost	`build.rs`	`cfg!(target_arch = ...)`, `cfg!(windows)`	Sets `CMAKE_SYSTEM_PROCESSOR` for the host and decides whether to build conformance tests.
uutils/coreutils	`build.rs`	`#[cfg(target_os = ...)]`	Sets `DYLIB_EXT` (`.so` / `.dylib` / `.dll`) for the host platform.
AFLplusplus/LibAFL	`build.rs`	`cfg!(target_os = "linux") && cfg!(target_arch = "x86_64")`	NYX only works on Linux x86_64 hosts; gates running a host-side build script.
webbeef/webviewer	`build.rs`	`cfg!(windows)`	Picks `python.exe` vs `python3` — a host tool name.

These came up immediately in my GH search; I didn't have to go digging. This makes me wonder about whether this lint would do more harm than good. It would seem, at least, that a crater run would be in order.

Urgau · 2026-04-01T20:00:15Z

It would seem, at least, that a crater run would be in order.

I'm planning on doing one before asking the teams for approval, but I first wanted a vide-check from T-cargo.

The implementation needs some work before we can do one though (renaming, removing the custom parser, ...).

Mark-Simulacrum · 2026-04-01T22:16:59Z

Is there a reason this can't be implemented via the existing check-cfg checks? Do we not support opting out of permitting built-in cfgs via check-cfg? If it can be done via check-cfg, is the reason this is a new lint just for better error messages (since we can guide the user about the build script specific context)?

I'm supposed to rewrite a big part of this lint to reuse existing cfg attribute parsing. Also the problem here is that we need to check all cfgs, including the ones that get removed early on and the cfg! macro. For that to work, we need to run before the expansion pass.

I don't think I follow this. cfg! does get checked by check-cfg lints, just like #[cfg]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=098a07edea7467a723355ea8931eb72e

GuillaumeGomez · 2026-04-09T14:34:15Z

Is there a reason this can't be implemented via the existing check-cfg checks? Do we not support opting out of permitting built-in cfgs via check-cfg? If it can be done via check-cfg, is the reason this is a new lint just for better error messages (since we can guide the user about the build script specific context)?

I'm supposed to rewrite a big part of this lint to reuse existing cfg attribute parsing. Also the problem here is that we need to check all cfgs, including the ones that get removed early on and the cfg! macro. For that to work, we need to run before the expansion pass.

I don't think I follow this. cfg! does get checked by check-cfg lints, just like #[cfg]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=098a07edea7467a723355ea8931eb72e

It's checked during the AST -> attribute conversion. But considering I need to store some extra info, I'm not sure it's gonna be the right place. First I rewrite using the attribute parser, then I see if I can merge both codes.

…t have a compiler output generated by the lint-docs script

…ustc lint

rustbot · 2026-04-10T13:14:57Z

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

rustbot · 2026-04-10T13:15:00Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

GuillaumeGomez · 2026-04-10T13:16:24Z

The last commit is not finished at all. It's currently blocked on #155097.

I'll also likely need to update the parse_cfg/parse_cfg_entry API because the lint provides a suggestion for cfg! and I'd like to keep it.

@JonathanBrouwer

…, r=JonathanBrouwer Make `rustc_attr_parsing::SharedContext::emit_lint` take a `MultiSpan` instead of a `Span` I'll likely need it for rust-lang#153721 to allow emitting the lint on one attribute at a time instead of each of the wrong values. r? @JonathanBrouwer

@JonathanBrouwer

Rollup merge of #155097 - GuillaumeGomez:emit_lint-multispan, r=JonathanBrouwer Make `rustc_attr_parsing::SharedContext::emit_lint` take a `MultiSpan` instead of a `Span` I'll likely need it for #153721 to allow emitting the lint on one attribute at a time instead of each of the wrong values. r? @JonathanBrouwer

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 11, 2026

rustbot assigned Urgau Mar 11, 2026

GuillaumeGomez force-pushed the misleading_cfg_in_build_script branch from 262d2e2 to 3e99ab7 Compare March 11, 2026 14:35

This comment has been minimized.

Sign in to view

GuillaumeGomez force-pushed the misleading_cfg_in_build_script branch from 3e99ab7 to ea1c733 Compare March 11, 2026 16:00

This comment has been minimized.

Sign in to view

Urgau reviewed Mar 11, 2026

View reviewed changes

GuillaumeGomez force-pushed the misleading_cfg_in_build_script branch from ea1c733 to 28c7221 Compare March 11, 2026 20:58

This comment has been minimized.

Sign in to view

ehuss added the I-cargo-nominated Nominated for discussion during a cargo team meeting. label Mar 13, 2026

ehuss added this to Cargo status tracker Mar 17, 2026

ehuss moved this to Nominated in Cargo status tracker Mar 17, 2026

Urgau reviewed Mar 18, 2026

View reviewed changes

GuillaumeGomez force-pushed the misleading_cfg_in_build_script branch from 2d14a6b to 06e2527 Compare March 19, 2026 13:34

This comment has been minimized.

Sign in to view

traviscross added T-lang Relevant to the language team I-lang-nominated Nominated for discussion during a lang team meeting. labels Mar 23, 2026

traviscross added I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-1 Lang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang labels Apr 1, 2026

GuillaumeGomez added 5 commits April 9, 2026 17:18

Make MetaItem::from_tokens public

fb58d15

Add new misleading_cfg_in_build_script rustc lint

1b7506c

Add ui test for new misleading_cfg_in_build_script lint

f46a931

Add misleading_cfg_in_build_script to the list of lints which canno…

a2d1567

…t have a compiler output generated by the lint-docs script

Remove is_build_script check for misleading_cfg_in_build_script r…

d6ed6a9

…ustc lint

This comment has been minimized.

Sign in to view

GuillaumeGomez mentioned this pull request Apr 10, 2026

Make rustc_attr_parsing::SharedContext::emit_lint take a MultiSpan instead of a Span #155097

Merged

Move misleading_cfg_in_build_script directly into attribute parsing

1518fcc

GuillaumeGomez force-pushed the misleading_cfg_in_build_script branch from b20987d to 1518fcc Compare April 10, 2026 13:14

rustbot added the A-attributes Area: Attributes (`#[…]`, `#![…]`) label Apr 10, 2026

Uh oh!

Conversation

GuillaumeGomez commented Mar 11, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Mar 11, 2026

Uh oh!

GuillaumeGomez commented Mar 11, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

Urgau Mar 11, 2026

Choose a reason for hiding this comment

Uh oh!

GuillaumeGomez Mar 11, 2026

Choose a reason for hiding this comment

Uh oh!

weihanglo Mar 13, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

GuillaumeGomez commented Mar 12, 2026

Uh oh!

ehuss commented Mar 17, 2026

Uh oh!

GuillaumeGomez commented Mar 17, 2026

Uh oh!

Urgau commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Urgau left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Urgau Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

GuillaumeGomez Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

Urgau Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

Urgau Mar 18, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

ehuss commented Mar 23, 2026

Uh oh!

GuillaumeGomez commented Mar 23, 2026

Uh oh!

nikomatsakis commented Apr 1, 2026

Uh oh!

traviscross commented Apr 1, 2026

Uh oh!

GuillaumeGomez commented Apr 1, 2026

Uh oh!

Mark-Simulacrum commented Apr 1, 2026

Uh oh!

GuillaumeGomez commented Apr 1, 2026

Uh oh!

nikomatsakis commented Apr 1, 2026

Uh oh!

traviscross commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Urgau commented Apr 1, 2026

Uh oh!

Mark-Simulacrum commented Apr 1, 2026

Uh oh!

GuillaumeGomez commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

rustbot commented Apr 10, 2026

Uh oh!

rustbot commented Apr 10, 2026

Uh oh!

GuillaumeGomez commented Apr 10, 2026

Uh oh!

GuillaumeGomez commented Mar 11, 2026 •

edited by rustbot

Loading

Urgau commented Mar 17, 2026 •

edited

Loading

Urgau left a comment •

edited

Loading

traviscross commented Apr 1, 2026 •

edited

Loading

GuillaumeGomez commented Apr 9, 2026 •

edited

Loading