Skip to content

Conversation

@simoll
Copy link
Collaborator

@simoll simoll commented Apr 24, 2025

  • Generalize long vector diagnostics code to HitObjects.
  • Diagnose unsupported use of HitObject in globals, entry params/returns and various other shader-kind-specific contexts.
  • Create HitObject variants from the invalid-longvec-decls*.hlsl tests to make sure all cases are covered.

Specification: https://github.com/microsoft/hlsl-specs/blob/main/proposals/0027-shader-execution-reordering.md

Closes #7234 [SER] Diagnose and validate illegal use of HitObject in unsupported contexts (discussed offline)

- Generalize long vector diagnostics code to HitObjects.
- Diagnose unsupported use of HitObject in globals, entry params/returns
  and various other shader-kind-specific contexts.
- Create HitObject variants from the invalid-longvec-decls*.hlsl tests
  to make sure all cases are covered.

Specification: https://github.com/microsoft/hlsl-specs/blob/main/proposals/0027-shader-execution-reordering.md

Bug: microsoft#7234 [SER] Diagnose and validate illegal use of HitObject in unsupported contexts
Copy link
Contributor

@tex3d tex3d left a comment

Choose a reason for hiding this comment

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

Mainly, I don't think we should be adding as much special-case code for HitObject, where the code should be the same for other object types, such as detecting whether we have an intangible HLSL object type inside another type decl. HitObject should be considered one of a variety of intangible HLSL object types that are handled uniformly in a bunch of contexts.

But also, combining the HitObject diagnostic with the long vector one is a bit confusing, as the contexts that disallow HitObject, and other intangible objects generally, are different than the contexts that disallow long vectors. This is conceptually a different rule.

@github-project-automation github-project-automation bot moved this from New to In progress in HLSL Roadmap Apr 24, 2025
@damyanp damyanp moved this to Active in HLSL Support Apr 25, 2025
@simoll
Copy link
Collaborator Author

simoll commented May 2, 2025

This is a major update. Changes:

  • Created a new err_hlsl_unsupported_object_context diagnostic. %select values are compatible with the err_hlsl_unsupported_long_vector one plus new entries for other contexts.
  • Folded err_hlsl_node_record_object and err_hlsl_objectintemplateargument into that new diagnostic.
  • Split off object diagnostic from long vector diagnostic again.
  • Created a one-stop diagnostic infra to tell whether an HLSL object is allowed in a certain context or not (eg see AllowObjectInContext).
  • Added HitObject test case for groupshared, static global variables (no) and regular user functions (only the last is allowed)
  • Using the infra for HitObject but this could be used for other object types in unsupported contexts (RayQuery, ..)

@simoll simoll changed the title [SER] Generalize long vector diagnostics to HitObject [SER] Diagnose HitObject in unsupported declaration contexts May 2, 2025
@simoll simoll requested a review from tex3d May 2, 2025 16:07
Copy link
Collaborator

@pow2clk pow2clk left a comment

Choose a reason for hiding this comment

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

So that's a lot of nitpicks from me. @tex3d still needs to reset his feedback for this to go in. As far as I can tell, the feedback he gave has mostly been responded to, but could further be addressed by merging the loose ContainsLongVector checks into DiagnoseTypeElements and its implementor functions, which I would also prefer.

@pow2clk
Copy link
Collaborator

pow2clk commented May 12, 2025

A large chunk of my nitpicks become moot if ContainsLongVec is merged as the TODO comment suggests.

@github-actions
Copy link
Contributor

github-actions bot commented May 13, 2025

✅ With the latest revision this PR passed the C/C++ code formatter.

@simoll
Copy link
Collaborator Author

simoll commented May 13, 2025

So that's a lot of nitpicks from me. @tex3d still needs to reset his feedback for this to go in. As far as I can tell, the feedback he gave has mostly been responded to, but could further be addressed by merging the loose ContainsLongVector checks into DiagnoseTypeElements and its implementor functions, which I would also prefer.

Thanks for the review. I've folded the CheckLongVector logic into DiagnoseTypeElements. This removed a lot of redundant code and the HLSLLongVector tracking bit as this is all handled by this one diagnostic function now.

@simoll simoll requested review from pow2clk and tex3d May 13, 2025 09:06
Copy link
Collaborator

@pow2clk pow2clk left a comment

Choose a reason for hiding this comment

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

Looks good! I have just a couple of nits you might consider if you end up making another iteration of this. I'm not sure why it says a merge resolution is required. When I tried to inspect the conflict, it showed zero conflicts.


/// \brief Whether this class contains at least one member or base
/// class containing an HLSL vector longer than 4 elements.
bool HasHLSLLongVector : 1;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I confess I didn't anticpate that merging the longvector check with the other type checks would result in removing this bit, but I see how it follows and I don't object.

const TypeDiagContext DiagContext = TypeDiagContext::TessellationPatches;
if (DiagnoseTypeElements(*m_sema, argLoc.getLocation(), arg.getAsType(),
TypeDiagContext::TessellationPatches))
DiagContext, DiagContext))
Copy link
Collaborator

Choose a reason for hiding this comment

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

As frequently as the pattern of both objects and long vectors having the same context occurs, it may make sense to have an overload of DiagnoseTypeElements that takes a single context that is propagated to both for the longer overload, but I won't insist on it if there are no other commits to be made to this PR that change might be packaged with.

case AR_TOBJ_OBJECT:
Empty = false;
if (AllowObjectInContext(Ty, DiagContext))
if (!CheckObjects || AllowObjectInContext(Ty, ObjDiagContext))
Copy link
Collaborator

Choose a reason for hiding this comment

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

I didn't expect and after review didn't observe any cases where the call to this would result in CheckObjects being false. There's nothing wrong with handling the condition in the interest of making it more robust, but I wanted to confirm I had that right.


// Disallow long vecs from $Global cbuffers.
if (!isStatic && !isGroupShared && !IS_BASIC_OBJECT(basicKind))
LongVecDiagContext = TypeDiagContext::CBuffersOrTBuffers;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I was imagining else if (!IS_BASIC_OBJECT(basicKind)) as the final else if after the else if (isStatic) on line 15378 which would result in something more concise, but I won't insist. If you make another change to the PR, you might consider that consolidation.

tex3d added 2 commits May 15, 2025 12:06
- Recurse bases in IsHLSLCopyableAnnotatableRecord
- Don't skip DiagnoseTypeElements for templated Load/Store
- Don't skip existing Payload diagnostics when DiagnoseTypeElements fails
- Update tests, including moving fields pointed to by notes to beginning
  to avoid shifting fixed location references when modifying test cases
Copy link
Collaborator

@pow2clk pow2clk left a comment

Choose a reason for hiding this comment

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

Looks good! Better diagnostics overall!

Copy link
Member

@damyanp damyanp left a comment

Choose a reason for hiding this comment

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

Approving based on previous approvals before the most recent change.

@tex3d tex3d merged commit f9c2d5d into microsoft:main May 16, 2025
12 checks passed
@github-project-automation github-project-automation bot moved this from Active to Closed in HLSL Support May 16, 2025
@github-project-automation github-project-automation bot moved this from In progress to Done in HLSL Roadmap May 16, 2025
@simoll simoll deleted the ser_diaghitobject_patch branch May 19, 2025 04:37
@damyanp damyanp removed this from HLSL Support Jun 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

[SER] Diagnose and validate illegal use of HitObject in unsupported contexts

4 participants