slang.git/source/slang/slang-check-stmt.cpp, branch master

Error if super-type capabilities are a super-set of sub-type (#7452)

2025-08-08T20:19:25+00:00

Fixes: #7410 Changes: 1. super-type capabilities must be a super-set of sub-type capabilities (and support the same shader stages/targets) * InheritanceDecl visits super-type to inherit it's capabilities; validate InheritanceDecl capabilities against sub-type * visit all container decl's with a default case * clean up functionDeclBase visitor * Simplify `diagnoseUndeclaredCapability` by moving logic into capability checking (more correct*) 3. added changed behavior to documentation 4. fixed some incorrect capabilities 5. **we do not** diagnose capability errors on interface requirement-to-implementation if both lack explicit capability requirements. This change is to work around a slangpy regression (test case for the failing situation is in `tests\language-feature\capability\capability-interface-extension-1.slang`), Note: maybe for slang-2026 we don't do this? 6. requirement & implementation must support the same shader stage/target. This was changed because otherwise we can have cases where `X` inherits from `Y`, but `Y` is only expected to be used in `glsl` whilst `X` is expected to be used in `hlsl | glsl` 7. removed `tests/language-feature/capability/capabilitySimplification3.slang` because it tests nothing special (redundant) Note: not using rebase due to separate branches depending on this PR --------- Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>

Add warning for comma operators used outside for-loops and expand expressions in legacy mode (#7984)

2025-08-07T08:01:02+00:00

This PR implements a warning system to help users identify potentially unintended comma operator usage in expressions. The comma operator can be confusing when used in contexts like variable initialization where users might have intended to use braces for initialization instead. ## Problem The following code compiles without error but is likely not written as intended: ```slang float4 vColor = (0.f, 0.f, 0.f, 1.f); // Uses comma operators, evaluates to 1.f ``` The intended code should use braces: ```slang float4 vColor = {0.f, 0.f, 0.f, 1.f}; // Proper initialization ``` ## Solution Added a new warning diagnostic (`commaOperatorUsedInExpression`, ID: 41024) that warns when comma operators are used in expressions, with exemptions for contexts where they are commonly intended: - **For-loop side effects**: `for (int i = 0; i < 10; i++, x++)` - no warning - **Expand expressions**: `expand(f(), g(each param))` - no warning - **Slang 2026+ mode**: `let m = (1,2,3)` creates tuples - no warning - **All other expressions**: `float4 v = (a, b, c, d)` and `return a, b` - warns for each comma ## Implementation Details - Added context tracking in `SemanticsContext` with `m_inForLoopSideEffect` flag - Modified `visitForStmt` to use special context when checking side effect expressions - Added comma operator detection in `visitInvokeExpr` for `InfixExpr` nodes - Added language version check using `isSlang2026OrLater()` to disable warnings in Slang 2026+ mode where parentheses create tuples - Performance optimization: language version check is hoisted to avoid unnecessary casting - Warning can be suppressed using `-Wno-41024` command line flag ## Test Coverage Added comprehensive test cases using filecheck format that verify: - Warnings are generated for comma operators in variable initialization (legacy mode only) - Warnings are generated for comma operators in return statements (legacy mode only) - Warnings are generated for comma operators in general expressions (legacy mode only) - No warnings for comma operators in for-loop side effects - No warnings in Slang 2026+ mode where parentheses create tuples - Warning suppression works correctly Example output (legacy mode): ``` warning 41024: comma operator used in expression (may be unintended) float4 vColor = (0.f, 0.f, 0.f, 1.f); ^ warning 41024: comma operator used in expression (may be unintended) return a *= 2, a + 1; ^ ``` Fixes #6732. --- 💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click [here](https://survey.alchemer.com/s3/8343779/Copilot-Coding-agent) to start the survey. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: aidanfnv <198290069+aidanfnv@users.noreply.github.com> Co-authored-by: slangbot Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com> Co-authored-by: aidanfnv Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>

Minimal optional constraints (#7422)

2025-06-28T02:39:24+00:00

* Parse optional witness syntax * Allow failing optional constraint * Make `is` work with optional constraint * Allow using optional constraint in checked if statements * Fix tests * Make it work with structs * Fix MSVC build error * Disallow using `as` with optional constraints * Update test to match split is/as errors * Add tests * Fix uninitialized variables in tests * Add tests of incorrect uses & fix related bugs * Mention optional constraints in docs * format code * Fix type unification with NoneWitness * Fix formatting --------- Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com> Co-authored-by: Nathan V. Morrical

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.

Implement throw & catch statements (#6916)

2025-05-23T19:27:37+00:00

* Implement throw statement It already existed in the IR, so only parsing, checking and lowering was missing. * Initial catch implementation Likely very broken. * Error out when catch() isn't last in scope * Prevent accessing variables from scope preceding catch As those may actually not be available at that point. * Add IError and use it in Result type lowering * Add diagnostic tests * Allow caught throws in non-throw functions * Fix catch propagating between functions & SPIR-V merge issue * Add test for non-trivial error types * Fix MSVC build * Fix invalid value type from Result lowering * Also lower error handling in templates * Lower result types only after specialization * Attempt to disambiguate error enums by witness table * Revert matching by witness, types should be distinct too * Don't assert valueField when getting Result's error value It may not exist if the function returns void, but getting the error value is still legitimate. * Update tests for new error numbers & get rid of expected.txt * Change catch lowering to resemble breaking a loop ... To make SPIR-V happy. * Fix dead catch blocks and invalid cached dominator tree * More SPIR-V adjustment * Lower catch as two nested loops * Add defer interaction test and revert broken defer changes * Fix enum type when throwing literals * Cleanup and bikeshedding * Document error handling mechanism * Fix table of contents * Use boolean tag in Result * Use anyValue storage for Result * Remove IError * Fix formatting * Eradicate success values from docs and tests * Use parseModernParamDecl for catch parameter * Implement do-catch syntax * Implement catch-all * Fix formatting * Fix marshalling native calls that throw --------- Co-authored-by: Yong He

Do not print errors in _coerce when "JustTrying". (#7064)

2025-05-15T01:55:17+00:00

* Do not print errors in _coerce when "JustTrying". While figuring out which generic-overload works best, `_coerce()` is printing errors and Slang compilation terminates prematurely. When `TryCheckGenericOverloadCandidateTypes()` is calling `_coerce()` in "JustTrying" mode, the error messages should be snoozed. The following logic shows the intention of how to silence the error messages, but the chain of `sink` was broken in the middle and `_coerce()` was using `getSink()` from the SemanticVisitor. val = ExtractGenericArgInteger( arg, getType(m_astBuilder, valParamRef), context.mode == OverloadResolveContext::Mode::JustTrying ? nullptr : getSink()); * Use tempSink when available.

Initial support for immutable lambda expressions. (#6914)

2025-04-30T21:17:45+00:00

* Initial support for immutable lambda expressions. * More diagnostics, and langauge server fix. * Language server fix. * Fix bug identified in review. * Add expected result. * Update expected result.

Fix attempt to construct an abstract AST node (#6905)

2025-04-24T21:19:45+00:00

Work on #6892 The function `tryInferLoopMaxIterations` in `slang-check-stmt.cpp` was doing: auto litExpr = m_astBuilder->create(); but the declaration of `LiteralExpr` in `slang-ast-expr.h` had been marked as abstract, during the switch to using the `slang-fiddle` tool to generate code: FIDDLE(abstract) class LiteralExpr : public Expr { ... } In this case, the intention of the AST design is that `LiteralExpr` should be kept abstract, and only the concrete subclasses should ever be instantiated. Because of some historical design choices, the `ASTNodeType` enumeration includes both the concrete and abstract AST classes, so the code ended up constructing a `LiteralExpr` that had the tag `ASTNodeType::LiteralExpr`. Then attempts to use the `ASTNodeDispatcher` code on such a node caused crashes, because the dispatcher code only included `case` statements for the non-abstract `ASTNodeType`s. The quick fix here was to change the `tryInferLoopMaxIterations` function to instead do: auto litExpr = m_astBuilder->create(); A test case was added to help catch any future regressions on this specific issue. A more long-term fix should involve introducing code that statically and/or dynamically prohibits the creation of instances of AST node classes that have been marked abstract.

Eliminate back-reference in ChildStmt (#6835)

2025-04-17T16:53:37+00:00

* Eliminate back-reference in ChildStmt This change is part of a larger effort to improve the code for AST serialization in the Slang compiler. Tree structures are understandably easier to serialize than DAGs, and DAGs are easier than fully generaal graphs. The Slang AST nodes form a tree structure... except when they don't. Among the exceptions to nice tree-structured ASTs are: 1. References to `Decl`s are encoded as pointers to the AST `Decl` nodes themselves. This can result in cycles in the graph, and requires care in serialization. 2. Nodes that inherit from `Val` represent, well, *values* instead of actual pieces of syntax, and as such they are deduplicated so that identical values will (hopefully) be identical pointers. This results in a DAG structure for `Val`s, but at least it's not a general graph (except for cycles that go through a `Decl`). 3. There are some minor cases of DAG-structured sharing that the parser can introduce to deal with cases when a traditional-style declaration includes multiple declarators. E.g., given: ``` static int a, b; ``` The resulting `DeclGroup` will include distinct `Decl`s for `a` and `b`, which will share the `static` modifier through a `SharedModifiers` node, and the `int` type specifier through a `SharedTypeExpr` node. This duplication can be ignored, for the purposes of serialization, since duplicating those parts of the AST has no major down-sides. 4. There is the case of `ChildStmt`, used for things like `break` and `continue`, which stores a direct `Stmt*` to the enclosing parent statement being targetted. Storing the target is useful so that IR lowering doesn't need to repeat the work that the semantic checking logic did to associate each child statement with its parent. The parent link inside of `ChildStmt` creates a cycle in the AST `Stmt` hierarchy, since the outer statement contains the inner, and the inner statement stores a pointer to the outer. This change eliminates the last of these sources of complication for AST serialization, by changing the `ChildStmt` type to stored an integer ID for the enclosing statement that it matches to, and having each `BreakableStmt` (used to represent the outer `switch`, or loop, or whatever) generate its own unique ID as part of semantic checking. Note: if necessary, it is reasonable for the outer statement to have its unique ID generated as part of parsing, rather than semantic checking. * format code * Change unique ID to be a proper Decl The fix here is to make the "unique ID" representation be a full `Decl`-derived AST node, so that it is both allowed to break the tree-structuring rules cleanly, and it is also trivially guaranteed to be unique across all loaded ASTs. * format code --------- Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>

Add defer statement (#6619)

2025-04-07T03:08:29+00:00