slang.git/source/slang/slang-reflection-api.cpp, branch master

Add FindModifier for Declarations (#8308)

2025-09-10T22:55:00+00:00

Add `findModifier` for `DeclReflection` so pattern like `extern struct foo;` can be properly reflected. Closes #8009

Fix FunctionReflection getName() returning null for overloaded functions (#8113)

2025-08-08T00:34:05+00:00

When using Slang reflection API to find functions by name in a type, `FunctionReflection::getName()` would return `nullptr` for overloaded functions instead of the expected function name. The issue occurred in `spReflectionFunction_GetName` when `findFunctionByNameInType` returned a `SlangReflectionFunction` wrapping an `OverloadedExpr` (for overloaded functions) instead of a single `DeclRef`. The `convertToFunc()` function would fail for `OverloadedExpr` objects, causing `getName()` to return `nullptr`. **Example of the bug:** ```cpp // This code would fail before the fix public interface IBase { public void step(inout float f); } public struct Impl : IBase { public void step(inout float f) { f += 1.0f; } } // Using reflection API: auto implType = reflection->findTypeByName("Impl"); auto stepFunction = reflection->findFunctionByNameInType(implType, "step"); auto name = stepFunction->getName(); // Would return nullptr ``` **Fix:** Modified `spReflectionFunction_GetName` to handle overloaded functions by falling back to the name of the first overload candidate when `convertToFunc` fails. This follows the same pattern already used by `spReflectionFunction_specializeWithArgTypes`. The fix ensures that: - Overloaded function containers return the correct function name - Individual overload candidates also return their names correctly - Non-overloaded functions continue to work as before - No regression in existing functionality **Testing:** Added comprehensive test cases covering both the original issue scenario and explicit function overloading. All existing reflection tests continue to pass. Fixes #8047. --- 💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com> Co-authored-by: Yong He Co-authored-by: ArielG-NV <159081215+ArielG-NV@users.noreply.github.com> Co-authored-by: slangbot Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>

Add reflection api for overload candidate filtering. (#8066)

2025-08-06T08:07:41+00:00

* Add reflection api for overload candidate filtering. * Fix API. * Fix. * Update build. * Update test. * Update formatting.

Allow Link time constant array length sizing, warn on unsupported functionality (#7067)

2025-07-01T15:36:02+00:00

* Add link time array layout test * Add link time constant array size compilation test * Link time constant array size test * Allow getting link time array size Closes https://github.com/shader-slang/slang/issues/6753 * format * Switch to SIMPLE test and check output * Implement without binary api changes * diagnose on link time constant sized array * fix test --------- Co-authored-by: Yong He

Hide atomics struct from reflection api (#7520)

2025-06-26T18:15:43+00:00

* Atomic reflection unit test Test that Atomic is reflected as a scalar/int instead of a struct named Atomic. * Hide AtomicType from reflection Leverage the fact that returned variables go through convert() to centralize the unwrapping of the AtomicType struct. Fixes #6257 * Clean up unit test a bit - rename bar to buf (since one of them is not Atomic and thus not a barrier) - validate deeper into the fields of bufC - remove debug code

Set current astbuilder for reflection API (#7488)

2025-06-26T08:21:51+00:00

With the test code in the issue, a crash was observed inside Slang::DeclRefBase::getParent() while accessing the astbuilder which was nullptr. This PR adds a fix for that. For the test code in the issue, we now get: ================================================ found Outer::Inner: true found foo function: true function name: "foo" parameter count: 1 attempting getParameterByIndex(0): true getParameterByIndex(0) succeeded: true parameter name: "param" parameter type: "float" ================================================ Fixes #6546

Mediate access to ContainerDecl members (#7242)

2025-06-09T18:22:51+00:00

Most of what this change does is straightforward: take all the places in the code that used to operate directly on `ContainerDecl::members` and related fields, and instead have them call into a smaller set of accessor methods defined on `ContainerDecl`. The primary motivation for making this change is that in order to implement on-demand loading of members from serialized AST modules, we need a way to identify and intercept the "demand" for those members. On-demand loading benefits from having all accesses to the members of a `ContainerDecl` be as narrow as possible. If a part of the code only need a member at a specific index, it should say so. If it only needs access to members with a specific name, or a given subclass of `Decl`, then it should say so. A secondary motivation for this change is that there have recently been several changes that added complexity and special cases by introducing code that operated on (and *mutated*) the member list of a container decl in ways that the existing code had never done before. Any code that mutates the member list of a `ContainerDecl` needs to be sure to not disrupt the invariants that the lookup acceleration structures currently rely on. One of the recent changes added a declaration-to-index map to the set of acceleration structures (with different validation/invalidation behavior than the others...) while other recent changes would remove or insert declarations in ways that could change the indices of other declarations in the same container. It is not clear if any of these pieces of code were aware of the others, and the invariants that might be expected or broken along the way. This change bottlenecks the vast majority of accesses to the members of a `ContainerDecl` through the following operations: * Getting a `List` of all of the direct member declarations of a container * Get the number of direct member declarations, and accessing them by index. * Looking up the list of direct member declarations with a given name. * Adding a new direct member declaration to the end of the list. Some other operations are layered on top of those (e.g., getting a list of all the direct member declarations of a given C++ class). These layered operations are still centralized on the `ContainerDecl`, with the intention that we *can* change them to be non-layered implementations if we ever need to for performance (e.g., by building a lookup structure for finding member declarations by their type). The exceptional cases of access/mutation on the direct members of a `ContainerDecl` have also been encapsulated, but rather than expose what would risk appearing like general-purpose accessors (e.g., `removeDecl(d)`, `setDecl(index)`, etc.), these operations have been explicitly named after the specific use case that they serve in the codebase today, to discourage others from using them for more kinds of operations we'd rather not support. These operations have also been given parameter signatures that match their use cases, to make it so that even somebody determined to abuse them would have to invent suitable arguments out of thin air. In the case of the declaration-to-index mapping, this change eliminates that acceleration structure, in favor or slightly more complicated (and possibly inefficient, yes) code at the use site. Over time, it would be good to closely scrutinize each of the use cases that requires more complicated interaction with the members of a `ContainerDecl`, to see whether any of them can be reframed in terms of the more basic operations, or if there is some clean abstraction we can introduce to make operations that mutate the member list feel like... hacky.

support specialization constant sized array (#6871)

2025-05-14T17:11:53+00:00

Close #6859 Goal of this PR We want to support an array whose size can be specialization constant for shared/global variable e.g. layout (constant_id = 0) const uint BLOCK_SIZE = 64; shared float buf_a[(BLOCK_SIZE + 5) * 4]; Overview of the solution: During IndexExpr check, we will loose the restriction to allow SpecConst passing, but the size parameter will not be a constant value because it cannot be folded into a constant, so we will make it follow the same logic as generic parameter value, and the size will be represented by FuncCallIntVal/PolynomialIntVal/DeclRefIntVal. During IR lowering, we will detect whether there is spec constant in the IntVal, and wrap the IRInst with a SpecConstRateType, and propagate the type though the lowering logic, such that the IntVal representing the array size will have SpecConstRateType. During spirv emit stage, if we detect that a IRInst has SpecConstRateType, we will emit it as SpecConstantOp. We have to implement new logic to emit OpSpecConstantOp, the existing emit logic doesn't support emitting OpSpecConstantOp, especially this op can embed arithmetic operation at global scope, where we can only emit arithmetic instruct at local. But there are only few instructs we need to support. Overview of the solution: This PR doesn't support generic, and we will create a separate PR to extend that, tracked in #6840.

Return non-escaped strings from user-defined attributes (#6735)

2025-04-07T14:01:50+00:00

Fixes #6624 This commit changes the behavior of getArgumentValueString() to return the string's value, instead of returning the string's token, as that token also contains the surrounding quotation marks. This commit also modifies the relevant unit test accordingly, to not check for the surrounding quotations.

Make image format reflection easier (#6550)

2025-03-20T06:38:52+00:00

* image format json reflection * format code * use direct include --------- Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>