Skip to content

[Design] Obey conditions in #[cfg(..)] and #[cfg_attr(..)]#623

Draft
sandersaares wants to merge 2 commits into
sourcefrog:mainfrom
sandersaares:design/obey-cfg
Draft

[Design] Obey conditions in #[cfg(..)] and #[cfg_attr(..)]#623
sandersaares wants to merge 2 commits into
sourcefrog:mainfrom
sandersaares:design/obey-cfg

Conversation

@sandersaares

Copy link
Copy Markdown
Collaborator

Today, the app does not understand the conditions #[cfg(..)] and #[cfg_attr(..)], always treating the conditions as true. This is a proposed design for fixing that (#50).

Opening PR to discuss design before any implementation work.

@sourcefrog WDYT?

Introduces design/obey-cfg.md describing a multi-phase pipeline (Candidate collection -> probe -> filter) for evaluating #[cfg(..)] and #[cfg_attr(..)] attributes via the Rust toolchain itself, rather than reimplementing cfg evaluation. Status: Draft.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

Adds a draft design document describing how cargo-mutants could start honoring conditional compilation (#[cfg(...)] / #[cfg_attr(...)]) by collecting cfg conditions during discovery, probing the active toolchain/cargo invocation to evaluate those conditions, and filtering candidates before producing mutants. This is intended to address issue #50 by avoiding mutants in cfg-dead code and by only honoring mutants::* attributes inside cfg_attr when their predicate is true.

Changes:

  • Add a detailed design proposal for a 3-phase pipeline: collect conditional candidates → probe toolchain for cfg truth values → filter to live mutants.
  • Specify a per-package probing mechanism implemented as an auto-generated integration test (tests/__cargo_mutants_probe.rs) executed with the same cargo flags/profile used for mutation testing.
  • Define proposed CLI/config surface (--ignore-cfg / ignore_cfg = true) and document edge cases/limitations (e.g., conditional #[path] non-goal).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread design/obey-cfg.md
Comment thread design/obey-cfg.md Outdated
Comment thread design/obey-cfg.md Outdated
@sandersaares sandersaares changed the title Obey conditions in #[cfg(..)] and #[cfg_attr(..)] [Design] Obey conditions in #[cfg(..)] and #[cfg_attr(..)] Jun 8, 2026
- is_live pseudocode: use get(...).unwrap_or(...) so unknown CfgExprs fall back conservatively to keep candidates live, per the rule in 5.4/6.3 (avoids a HashMap-indexing panic that would contradict the spec).

- Prerequisite bullet: reword to describe the prerequisite change to DiscoveryVisitor (exclude-re-attr scope stack) instead of linking the word 'branch' to src/visit.rs, which was confusing.

- Phase-B flow diagram: replace the stray 'CMP|cNNNN|0|1' with the 'CMP|<id>|<0|1>' template that matches the 5.4 protocol (three pipe-separated fields, not four).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@sourcefrog

Copy link
Copy Markdown
Owner

Hey I appreciate the thought and I would like to add this feature. But I also think that reviewing 1000 line AI-generated docs and PRs is going to make this spare-time passion project much less enjoyable and motivating for me.

Obviously we all have a lot to work through to understand what it means to do open source in the era of agentic coding.

@sandersaares

Copy link
Copy Markdown
Collaborator Author

Sure, feel free to engage or not-engage with the topic to the level of your comfort. What do you suggest as a useful course to get such features into the tool?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants