[Arkadiusz Lachowicz (AnastaZIuk)]

Summary

This clears stale delayed ODR-use bookkeeping before starting a lexed inline method body.

It also adds a small SPIR-V regression test for the same parser path.

Root cause

The missing cleanup is in ParseLexedMethodDef, which was introduced in 6ee4074a4.

That path enters ActOnStartOfFunctionDef(...) without first calling CleanupVarDeclMarking().

HLSL constant-expression references inside declarations such as [[vk::binding(Bindings::Mask, SessionDSIndex)]] can leave entries in MaybeODRUseExprs.

When the next lexed inline method is parsed, ActOnFinishFunctionBody(...) trips the debug invariant:

Leftover expressions for odr-use checking

Impact

This crashes assert-enabled DXC builds on valid HLSL.

Public release-like builds usually compile the same source because assertions are off, so the bug is masked rather than absent.

Repros

• Original immutable input from NSC -P: godbolt.org/z/81nsEja1v
• New minimized repro now checked into tools/clang/test/CodeGenSPIRV/ex40-lexed-inline-method-odr-use-crash.hlsl: godbolt.org/z/3zfraP9bf

Both CE links use the public dxc_trunk build, so they compile there because that build does not expose the local debug assert path.

[Chris B (llvm-beanz)]

The test case provided in the PR does not fail with DXC without this patch. The Linked godbolt contains loads of invalid HLSL and errors as a result of the invalid code.

The LLM-spew in the description does not give me any indication why this change is warranted or correct, and modern Clang does not have this change, so it doesn't seem to be correct for C++.

For all of those reasons I'm going to close this PR. If you believe there is something we should actually fix here, please provide an updated patch with a concrete test case and a human-written explanation of why it is necessary and correct.

[Arkadiusz Lachowicz (AnastaZIuk)]

Chris B (@llvm-beanz)

modern Clang does not have this change, so it doesn't seem to be correct for C++.

That conclusion is false and Clang does the cleanup earlier, see #9072.