Reject context-dependent enum discriminants

[joshlf]

Derives that validate enum tags copy explicit discriminants into a helper
enum. Context-dependent expressions can evaluate differently in that helper,
allowing the generated validator to accept an invalid original-enum tag.

Restrict copied discriminants to a compiler-defined, repeatable grammar of
integer and byte literals with primitive arithmetic and bitwise operations.
Reject paths, macros, calls, casts, attributes, and other context-bearing
forms before emitting any unsafe impl. Preserve the skip-on-error dependency
chain for exhaustive enums, including fieldful variants whose zero tag cannot
be identified syntactically, and add cross-toolchain regressions.

Closes #3619

Authored by an AI agent acting on Josh Liebow-Feeser's behalf.

---

• 　  Reject derive inputs that capture generated helpers #3635
• 👉 Reject context-dependent enum discriminants #3631

Latest Update: v10 — Compare vs v9

📚 Full Patch History

Links show the diff between the row version and the column version.

Version	v9	v8	v7	v6	v5	v4	v3	v2	v1	Base
v10	v9	v8	v7	v6	v5	v4	v3	v2	v1	Base
v9		v8	v7	v6	v5	v4	v3	v2	v1	Base
v8			v7	v6	v5	v4	v3	v2	v1	Base
v7				v6	v5	v4	v3	v2	v1	Base
v6					v5	v4	v3	v2	v1	Base
v5						v4	v3	v2	v1	Base
v4							v3	v2	v1	Base
v3								v2	v1	Base
v2									v1	Base
v1										Base

⬇️ Download this PR

Branch

git fetch origin refs/heads/Gifjr6pbpu4fh6t7qbzuuqczj3odny3ck && git checkout -b pr-Gifjr6pbpu4fh6t7qbzuuqczj3odny3ck FETCH_HEAD

Checkout

git fetch origin refs/heads/Gifjr6pbpu4fh6t7qbzuuqczj3odny3ck && git checkout FETCH_HEAD

Cherry Pick

git fetch origin refs/heads/Gifjr6pbpu4fh6t7qbzuuqczj3odny3ck && git cherry-pick FETCH_HEAD

Pull

git pull origin refs/heads/Gifjr6pbpu4fh6t7qbzuuqczj3odny3ck

Stacked PRs enabled by GHerrit.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-09T03:58:16.567595Z	65f60cb	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.86%. Comparing base (cb6d16d) to head (65f60cb).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3631   +/-   ##
=======================================
  Coverage   91.86%   91.86%           
=======================================
  Files          20       20           
  Lines        6097     6097           
=======================================
  Hits         5601     5601           
  Misses        496      496           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ab71f17c6c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[joshlf]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Breezy!

Reviewed commit: 0724207ed6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[joshlf]

@codex review

Authored by an AI agent acting on Josh Liebow-Feeser's behalf.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ac19a3c009

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[joshlf]

@codex review

Authored by an AI agent acting on Josh Liebow-Feeser's behalf.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. 👍

Reviewed commit: 219b88ef8a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[joshlf]

We should be able to support this by scanning and normalizing any Self tokens that appear in the token stream, being careful to understand when they refer to the type in question and when they might be nested inside of other type definitions (e.g., inside a [u8; { ... }] where ... is const code that itself contains a type definition and an impl block), and being careful to normalize raw vs non-raw identifiers as in the earlier PR. That will mean we don't have to reject the code that this PR currently rejects.

[joshlf]

Did you miss #3631 (comment)? Make sure to check top-level comments too.

[joshlf]

Authored by an AI agent acting on Josh Liebow-Feeser's behalf.

I did miss the top-level comment on the earlier pass. I have now fetched the complete top-level conversation as well as inline threads, investigated the proposed normalization, and replied with the language-level counterexample here: #3631 (comment)

[joshlf]

Authored by an AI agent acting on Josh Liebow-Feeser's behalf.

I investigated the scope-aware rewrite. We can mechanically distinguish outer Self from nested item/impl scopes, normalize raw identifiers, and rewrite outer Self to a fresh alias of the source enum. Unfortunately, that fixes only name resolution; it does not make copying the discriminant sound. The helper still performs a second const evaluation (and potentially a second macro expansion) independently of the source enum.

A concrete accepted counterexample is:

#![feature(core_intrinsics)]
#![allow(internal_features)]
#[repr(u8)]
enum Packet {
    Flag(bool) = Self::tag(),
    Raw(u8),
}
impl Packet {
    const fn tag() -> u8 {
        core::intrinsics::is_val_statically_known(0) as u8
    }
}

The official intrinsic contract says this safe const fn nondeterministically returns true or false, that two identical calls need not agree, and that unsafe code may never rely on a particular answer. If the source enum gets 1 and the normalized helper gets 0, the real tags are {Flag: 1, Raw: 2} while the helper tags are {Flag: 0, Raw: 1}. Bytes with real tag 1 and an invalid bool payload are then checked as helper variant Raw(u8) and accepted. This recreates the soundness bug even though every Self resolves to Packet. The contract is documented in core::intrinsics::is_val_statically_known; I also compile-checked this enum shape on that exact nightly.

The nested-item case has another independent problem: copying the block creates fresh nominal and anonymous types. Their repr(Rust) layouts need not agree across identities (I reproduced differing size_of results with randomized layout), while copied impls can also cause duplicate-definition/coherence errors. A macro is opaque to the derive before expansion and can emit either contextual Self or a different value on its second expansion.

I could not find a stable way around the second evaluation for data-bearing enums. The Reference specifies that mem::discriminant is opaque and cannot yield the numeric value; numeric casts are available only for unit-only or otherwise qualifying fieldless enums. Reading a tag through the primitive-representation pointer technique requires an already-valid enum value, so it cannot bootstrap TryFromBytes validation.

For that reason, I think the current positive grammar is the necessary conservative boundary for this derive/helper architecture. We can add individual forms only when their repeatability is proved. Full support would require numeric discriminant reflection from the compiler or a source-owning macro/API that defines the source and validation tags from one canonical evaluation; a derive cannot retroactively rewrite the source enum. A separate fieldless-enum path could use casts of the original variants, but it would not solve the data-bearing case in #3619.

[joshlf]

@codex review

Please review exact head 65f60cb70fe351add4707ada01320aa160a91a01.

Authored by an AI agent acting on Josh Liebow-Feeser's behalf.

[chatgpt-codex-connector]

You have reached your Codex usage limits for security reviews. Please try again later.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. 👍

Reviewed commit: 65f60cb70f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[joshlf]

Authored by an AI agent acting on Josh Liebow-Feeser's behalf.

I investigated the scope-aware rewrite. We can mechanically distinguish outer Self from nested item/impl scopes, normalize raw identifiers, and rewrite outer Self to a fresh alias of the source enum. Unfortunately, that fixes only name resolution; it does not make copying the discriminant sound. The helper still performs a second const evaluation (and potentially a second macro expansion) independently of the source enum.

A concrete accepted counterexample is:

#![feature(core_intrinsics)]
#![allow(internal_features)]
#[repr(u8)]
enum Packet {
    Flag(bool) = Self::tag(),
    Raw(u8),
}
impl Packet {
    const fn tag() -> u8 {
        core::intrinsics::is_val_statically_known(0) as u8
    }
}

The official intrinsic contract says this safe const fn nondeterministically returns true or false, that two identical calls need not agree, and that unsafe code may never rely on a particular answer. If the source enum gets 1 and the normalized helper gets 0, the real tags are {Flag: 1, Raw: 2} while the helper tags are {Flag: 0, Raw: 1}. Bytes with real tag 1 and an invalid bool payload are then checked as helper variant Raw(u8) and accepted. This recreates the soundness bug even though every Self resolves to Packet. The contract is documented in core::intrinsics::is_val_statically_known; I also compile-checked this enum shape on that exact nightly.

The nested-item case has another independent problem: copying the block creates fresh nominal and anonymous types. Their repr(Rust) layouts need not agree across identities (I reproduced differing size_of results with randomized layout), while copied impls can also cause duplicate-definition/coherence errors. A macro is opaque to the derive before expansion and can emit either contextual Self or a different value on its second expansion.

I could not find a stable way around the second evaluation for data-bearing enums. The Reference specifies that mem::discriminant is opaque and cannot yield the numeric value; numeric casts are available only for unit-only or otherwise qualifying fieldless enums. Reading a tag through the primitive-representation pointer technique requires an already-valid enum value, so it cannot bootstrap TryFromBytes validation.

For that reason, I think the current positive grammar is the necessary conservative boundary for this derive/helper architecture. We can add individual forms only when their repeatability is proved. Full support would require numeric discriminant reflection from the compiler or a source-owning macro/API that defines the source and validation tags from one canonical evaluation; a derive cannot retroactively rewrite the source enum. A separate fieldless-enum path could use casts of the original variants, but it would not solve the data-bearing case in #3619.

Is there some subset of Self-containing ASTs which we can accept? For example, IIUC, Self::CONST should be fine since it cannot invoke macro or function code, right? Help brainstorm the maximum such subset. We can reject the rest.