[SPIR-V] Preserve members after merged bitfields in flat conversions

[dnovillo]

Since I was doing bitfield fixes in #8713, I took this one too.

This PR fixes #8526.

Copying a ConstantBuffer value with merged bitfields into a local struct overwrites the members after the bitfields. For struct MyData { uint a : 16; uint b : 16; uint c; }, reading c returns the word holding a and b.

This change makes processFlatConversion pick the decomposition mode from the source and destination AST types. A same-type conversion emits one scalar per SPIR-V field. But a cast that changes the shape, keeps one scalar per AST field.

I added the test from the original issue.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[dnovillo]

@pow2clk please review. Thanks.

[Copilot]

Pull request overview

Fixes SPIR-V flat conversion of constant-buffer structs containing merged bitfields, preserving members that follow those bitfields.

Changes:

• Selects decomposition mode based on source and destination AST types.
• Supports decomposing merged bitfields as one physical field.
• Adds regression coverage for copying into a local struct.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
tools/clang/lib/SPIRV/SpirvEmitter.cpp	Implements layout-aware scalar decomposition.
tools/clang/lib/SPIRV/SpirvEmitter.h	Updates the decomposition API.
tools/clang/test/CodeGenSPIRV/type.constant-buffer.fn-var.bitfield.hlsl	Verifies preservation of post-bitfield members.

---

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

[pow2clk]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[pow2clk]

I hate to harp on a comment, but I had this change all backwards expecting that bitfields were expected to make the comparison mismatch, leading to a true for mergebitfields, which was the existing behavior. I think this comment makes more clear why setting the boolean that way chooses the correct index.

[pow2clk]

This comment confused me as it states the truth, but doesn't mention how that should impact merged bitfields. The PR comment has a good description that I've slightly expanded.

Suggested change

	// Converting the same AST type between layouts preserves its physical field
	// sequence. Shape-changing flat conversions operate on AST fields.
	// A same-type conversion emits one scalar per SPIR-V field, but a cast that
	// changes the shape, keeps one scalar (potentially with merged bitfields) per
	// AST field. includeMergedBitfields determines which indexing is used.

[damyanp]

[Auto-generated note from @damyanp]

Did you consider adding a release note?

Per our CONTRIBUTING guidance, user-visible bug fixes and new features usually need an entry in docs/ReleaseNotes.md. If this PR is part of a larger multi-PR effort, a single shared release note across that effort is totally fine.