tl;dr see [D130055] yolo, woot, & kaboom
The basic problem I’m trying to solve is for HLSL. HLSL has a number of data types that define resources which need to be bound by the GPU driver. When resource objects are defined in translation-unit scope binding information is generated for the driver, but variables of the resource object types are also allowed to be passed as parameters and declared as local variables.
When a local variable is created HLSL requires that the local variable either be initialized from one for the global definitions, or that it be initialized from the global resource heap (conceptually an array of resource handles).
When a resource is passed as a parameter HLSL requires that the call be inlined and that the resource similarly can be resolved back to a global.
In the current HLSL compiler, we perform this analysis and validation on post-optimization IR. There are some huge downsides to that, one of the biggest being providing meaningful source locations for the error.
In thinking this problem through, the analysis required here isn’t super complicated, and seemed a lot like the analysis for -Wuninitialized. As I looked at how uninitialized value analysis is performed I believe we can actually largely model what we need inside the C++ construction rules if we have a few things:
(1) A way to annotate non-initializing constructors (
(2) A way to annotate initializing functions (
(3) A way to annotate functions that require initialized objects (
Earlier this week I (somewhat facetiously) posted a code review for a new proposed language extension. My amusing names aside, I think the feature is interesting and wanted to widen the discussion.
In particular I think there are cases of classes (like tagged unions, or builder pattern objects), where being able to annotate the initialization would allow for compiler diagnostics on usage patterns that the compiler would have significant trouble intuiting itself.