Skip to content

CFI: Cover each InstanceKind explicitly and reorganize UI tests - #160230

Open
rcvalle wants to merge 2 commits into
rust-lang:mainfrom
rcvalle:rust-cfi
Open

CFI: Cover each InstanceKind explicitly and reorganize UI tests#160230
rcvalle wants to merge 2 commits into
rust-lang:mainfrom
rcvalle:rust-cfi

Conversation

@rcvalle

@rcvalle rcvalle commented Jul 30, 2026

Copy link
Copy Markdown
Member
  • Changes transform_instance to cover each InstanceKind (and ShimKind) explicitly, similarly to how encoding is done, so the intent is expressed clearly and it is known when an instance is handled (or not) and the side effects of it (also clearly), instead of relying on fallthrough behavior. This also makes adding a new InstanceKind (or ShimKind) result in a compile-time error until it is explicitly handled. No functional changes intended.
  • Reorganizes the CFI and KCFI UI tests under the cfi and kcfi directories similarly to how the CFI codegen tests are organized: each test now tests a type or a language construct or feature that is handled by the CFI and KCFI transform or encoding, with complete coverage of what can be exercised at run time, and is named works-with-, and tests that covered both CFI and KCFI using revisions are split into separate tests. It also adds tests for the types, language constructs, and features that were not covered (i.e., intrinsics, thread locals, builtin Clone and FnPtr implementations, pattern types, the never type, extern types, C variadics, and the generalize-pointers and normalize-integers options), removes the tests that became redundant, and changes the drop tests to run-pass, as they now pass at run time. Tests for flags/options are unchanged (only moved into the cfi and kcfi directories when at the top level).

r? @bjorn3

Changes transform_instance to cover each InstanceKind (and ShimKind)
explicitly, similarly to how encoding is done, so the intent is
expressed clearly and it is known when an instance is handled (or not)
and the side effects of it (also clearly), instead of relying on
fallthrough behavior. This also makes adding a new InstanceKind (or
ShimKind) result in a compile-time error until it is explicitly handled.
No functional changes intended.
@rustbot rustbot added A-tidy Area: The tidy tool PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 30, 2026
@rcvalle rcvalle added the A-control-flow-integrity Area: Control Flow Integrity (CFI) security mitigation label Jul 30, 2026
Reorganizes the CFI and KCFI UI tests under the cfi and kcfi
directories similarly to how the CFI codegen tests are organized: each
test now tests a type or a language construct or feature that is
handled by the CFI and KCFI transform or encoding, with complete
coverage of what can be exercised at run time, and is named
works-with-<type-construct-or-feature>, and tests that covered both CFI
and KCFI using revisions are split into separate tests.

It also adds tests for the types, language constructs, and features
that were not covered (i.e., intrinsics, thread locals, builtin Clone
and FnPtr implementations, pattern types, the never type, extern types,
C variadics, and the generalize-pointers and normalize-integers
options), removes the tests that became redundant, and changes the drop
tests to run-pass, as they now pass at run time.

Tests for flags/options are unchanged (only moved into the cfi and kcfi
directories when at the top level).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-control-flow-integrity Area: Control Flow Integrity (CFI) security mitigation A-tidy Area: The tidy tool PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants