| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
| |
On the shader-host-callable target, test `gh-4874.slang` generates IR
that contains global constants referencing global params. These need to
get inlined into functions, as otherwise
`introduceExplicitGlobalContext()` will fail with "no outer func at use
site for global", making the test crash the compiler.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
`SemanticsVisitor::CheckInvokeExprWithCheckedOperands` made several
references to `expr` parameter in its `inout` parameter l-value-ness
validation logic to access arguments, which is wrong because `expr` is
not necessarily the same as `result`/`invoke` (the result of calling
`ResolveInvoke()` in the first line of the function. Changing it to
`invoke` for consistency.
Also add a special case logic to return early in case the resolved
invoke expr is `argument[0]` when the original invoke expr is
`T(funcThatReturnsT())`.
Closes #8659.
|
| |
|
|
|
|
|
| |
`MakeVector/MatrixFromScalar` (#8512)
- Allows using `Vector/Matrix` type with yet unresolved dimensions
- Simpler implementation and in-line with default `Array`
- Added `test/bugs/gh-8512.slang`
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a type mismatch issue. See the generated cuda code
```cuda
struct Query_0
{
EmptyExample_0 query_0;
uint hasNonEmptyAbsorbingBoundary_0;
};
struct Query_1
{
uint hasNonEmptyAbsorbingBoundary_0;
};
struct GlobalParams_0
{
Query_0* gQuery_0;
RWStructuredBuffer<float3 > gInput_0;
RWStructuredBuffer<float> gOutput_0;
};
...
Query_1 _S4 = *globalParams_0->gQuery_0; // ==> type mismatch at call site!
```
**Root Cause:** During the empty type legalization pass in Slang's IR
processing, struct types were being optimized. e.g., `Query_0` →
`Query_1` with empty type removed), but this created an inconsistency:
**Function parameters were updated:** When Query_compute_0 function was
legalized, its parameter type was correctly updated from `Query_0` to
the optimized `Query_1`
**Global parameter types were NOT updated:** The
`ParameterBlock<Struct>` type in globalParams still referenced the old
`Query_0` type
The PR adds special handling for type operands in the `legalizeInst`
function. This triggers the legalization of the `StructType` from the
original `legalizeOperand` call site. The leaglized result will be saved
in the type-to-legal-type map and be re-used when the same type requires
legalization again (e.g. in the `IRFunc` as parameter)
Fixes: https://github.com/shader-slang/slang/issues/7905
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Overview
========
This change is the start of an attempt to address how the Slang compiler
codebase has ended up conflating two similar, but semantically distinct,
concepts:
* The long-standing notion of `ref` parameters (only allowed for use in
the builtin modules), which are encoded using a wrapper `Type` in the
AST as part of the representation of the parameters of a `FuncType`.
* A recently-introduced notion of explicit reference types that mirror
the built-in `Ptr` type, with a relationship comparable to that between
pointer and reference types in C++.
The change splits the `Ref<T>` type in the core module into two distinct
types, with one for each of the two use cases. Similarly, the `RefType`
class in the compiler's AST is split into two distinct classes, to
represent the two cases.
Background
==========
The `Ref<T>` type in the core module (hidden and not intended for users
to ever see or use) was originally introduced to encode the `ref`
parameter-passing mode, comparable to the hidden `Out<T>` and `InOut<T>`
types used to encode `out` and `inout` parameter-passing modes. The
`Ref<T>` type in the core module was encoded as a instance of the
`RefType` class in the Slang AST (similar to how `Out<T>` mapped to an
`OutType`). These AST classes were *only* intended to be used by the
compiler front-end as part of its encoding of function types. The
`FuncType` class needed a way to distinguish an `inout int` parameter
from a plain (implicitly `in`) `int` parameter, so these wrapper like
`RefType` and `OutType` were introduced to encode both the parameter
type (`T`) and the parameter-passing mode in a form that could be passed
around as a `Type`.
Notably, the `Ref<T>` type (and `Out<T>`, etc.) were *not* intended to
be type names that ever get uttered in Slang code (not even in the
builtin modules), and the vast majority of the compiler code was not
supposed to ever encounter them. They were an implementation detail of
`FuncType`, and nothing else.
(In hindsight it may have been a mistake to use a nominal type declared
in the core module to implement these wrappers; it might have been a
good idea to use an entirely separate class of `Type` for this case...)
Recent changes to the builtin modules introduced functions that wanted
to *return* a reference (so that the parameter-passing-mode modifiers
like `ref` could not trivially be used), and as part of those changes
the appealingly-named `Ref<T>` type in the core module was re-used for
this new case. Builtin operations were declared with an explicit
`Ref<T>` return type, and parts of the compiler front-end that had
previously been blissfully unaware of the AST's `RefType` (and
`InOutType`, etc.) had to start accounting for the possibility that an
explicit `Ref<T>` would show up.
Related changes also introduced a comparable conflation of the
(unfortunately-named) `constref` parameter-passing modifier and builtin
operations that wanted to return an explicit reference that is
read-only. Both use cases were mapped to the core-module `ConstRef<T>`
type, which appeared in the AST as an instance of the `ConstRefType`
class.
The overlapping use of `ConstRef<T>`` is actually significantly more
troublesome than the `Ref<T>` case because, despite what its name
implies, `constref` was not really supposed to be the read-only analogue
of `ref`, but rather it is closer to the "immutable value borrow"
analogue to `inout`'s "mutable value borrow." The semantics of a "value
borrow" vs. a "memory reference" in Slang have not been very carefully
codified, and the conflation around `ConstRef<T>` has contributed to
things becoming increasingly muddy in the compiler back-end.
Main Changes
============
Core Module
-----------
The `Ref<T>` type has been replaced with two distinct types, with one
for each use case:
* `RefParam<T>` is intended for use when encoding a `ref` parameter in a
function type
* `ExplicitRef<T>` is intended for use when an operation in a builtin
module wants to return a reference
The other types used to represent parameter-passing modes (e.g.,
`InOut<T>`) were renamed to better indicate that their role in defining
parameter types (e.g., `InOutParam<T>`).
The `ExplicitRef<T>` type was given additional generic parameters for
the allowed access and the address space, akin to what `Ptr<T>` now
supports. The pointer dereference operator (prefix `*`) in the core
module should now properly propagate the access and address space of the
pointer over to the reference that gets returned.
The two distinct use cases of `ConstRef<T>` were not split in the way as
`Ref<T>`, instead the case for the `constref` parameter-passing mode
uses `ConstParamRef<T>`, while cases that previously used `ConstRef<T>`
to represent a read-only explicit reference instead now use
`ExplicitRef<T, Access.Read>`.
Prior to this change there were two subscripts declared on pointers: one
in the `Ptr` type itself, and another in an `extension` for pointers
with `Access.ReadWrite`. The comments on the code seemed to indicate
that the catch-all subscript used to only have a `get` accessor, while
the `ref` was only available on read-write pointers, but it seems that
subsequent changes converted the default subscript to support `ref`.
This change eliminates the subscript added via `extension`, since it is
redundant.
AST and Front-End
=================
Similar to the changes in the core module, the AST `RefType` class was
split into:
* `RefParamType` for the case of encoding `ref` parameters
* `ExplicitRefType` for the case where the user meant an explicit
reference type
All the other classes that represent wrappers for encoding
parameter-passing modes (e.g., `OutType`) were similarly renamed (e.g.,
`OutParamType`).
The `ConstRefType` class was simply renamed to `ConstRefParamType`,
because any use cases of `ConstRefType` that intended an explicit
reference type will now use `ExplicitRefType` with `Acccess.Read`.
For convenience, this change includes type aliases to map the old names
for these types over to the new ones (e.g., `using OutType =
OutParamType`) so that the change doesn't need to affect quite so many
lines of code. The `RefType` and `ConstRefType` names are intentionally
left undefined, since it woudl be unsafe to assume that existing use
sites should default to either of the two possible interpretations.
All use cases of `RefType` and `ConstRefType` (and their former shared
base class `RefTypeBase`) were audited and updated to refer to either
`RefParamType`/`ConstRefParamType` or `ExplicitRefType`, as appropriate
(based on whether the context of the code indicated it was working with
parameter-passing mode wrapper types, or explicit reference types).
In many (many) cases comments were added to the code that was updated
(and some unrelated code that needed to be audited along the way) to
note cases where there appears to be something fishy going on in the
compiler and/or there are obvious opportunities for next-step
improvement.
The `QualType` constructor used to infer l-value-ness when passed a
`RefType` or `ConstRefType`; that code was introduced to support
explicit reference types. The code was updated to consult the access
argument of an `ExplicitRefType` to try and determine the right
l-value-ness to use. There is some ambiguity about what should be done
in the case where the value of the generic argument representing the
access cannot be statically determined; a better solution may be needed.
Many other cases in the front-end that were working with `RefType` and
`ConstRefType` for explicit references also need to figure out
l-value-ness, and these were changed to rely on the logic already added
to `QualType` so that it wouldn't have to be duplicated. It isn't clear
if this structure is the best way to tackle the problem, but it seems to
at least be an upgrade over the more strictly ad-hoc logic that was in
place before.
Future Work
===========
IR-Level Work
-------------
The most obvious next step to take is that the split that was made in
the compiler front-end needs to be properly plumbed through all of the
back-end. There appears to be a lot of code in the back end of the
compiler that has made the same conflation of `ref` parameters and
explicit reference types that the front-end did. In practice, any uses
of `ExplicitRef<T>` in the front-end should desugar into plain
pointer-based code in the IR.
Clean Up Parameter-Passing Modes
--------------------------------
The code that handles different parameter-passing modes
(`ParameterDirection`s) and their wrapper types is somewhat scattered
and messy (as found while auditing use cases of `RefType`). A cleanup
pass is warranted to ensure that most code only needs to think about
`ParameterDirection`s. There should ideally be only a single operation
in the front-end that handles determining the `ParameterDirection` of a
parameter based on its modifiers. Similarly, there should be one
operation to wrap a value type based on a parameter direction, and one
operation to derive a `ParameterDirection` from the wrapper type.
Ideally, the accessors for `FuncType` should not provide unrestricted
access to the potentially-wrapped parameter types, and should instead
return some kind of `ParamInfo` struct that encodes both a
`ParameterDirection` and the unwrapped `Type` of the parameter.
Clean Up `QualType`
-------------------
A significant piece of future work that appears required is to
drastically clean up and improve the way that `QualType`s are represente
and handled in the front-end. There are currently various distinct
`bool` flags in `QualType` (some with very unclear meaning) and
differnet parts of the codebase consult/modify only subsets of them; a
clear enumeration of the "value categories" (to use the C++ terminology)
that Slang supports could be quite helpful. Naively, a `QualType` should
at least encode the basic information that a `Ptr` type encodes:
* A value type
* Allowed access (read-only, read-write, etc.)
* Address space
The main additional thing that a `QualType` needs is a way to
distinguish cases where an expression evaluates to:
* A reference to a memory location, where all the information from a
`Ptr` is relevant
* A simple value, such that the access and address space are irrelevant
* A reference to an abstract storage location (a `property`,
`subscript`, or an implicit conversion that needs to support being an
l-value), in which case address space is irrelevant and the "allowed
access" basically amounts to a listing of the accessors the storage
location supports
Eliminate Explicit Reference Types
----------------------------------
Finally, twe should eventually eliminate the `ExplicitRef<T>` type from
the core module (and all of the supporting code from the front-end),
since the feature is not a good fit for the Slang language. We should
find some other way to decorate operations in the builtin module that
need to returns a reference rather than a value (note how `ref`
accessors already avoided exposing explicit reference types, by design).
---------
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
| |
Changes default for render-test to sm_6_5.
Since sm_6_5 is the new default, remove the -use-dxil option, add
-use-dxcb option
Remove -use-dxil option from all test cases.
Add -use-dxcb to two tests that needed it.
Fixes #7611
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Resolves #7628
Resolves: #8197
Primary Goals:
1. Add `Access` to pointer
2. AddressSpace::GroupShared support for pointers (SPIR-V)
3. Add `__getAddress()` to replace `&`
* `&` is not updated to `require(cpu)` since slangpy uses `&`. This
means we must: (1) merge PR; (2) replace `&` with `__getAddress()`; (3)
add `require(cpu)` to `&`
Changes:
* Added to `Ptr` the `Access` generic argument & logic (for
`Access::Read`).
* Moved the generic argument `AddressSpace` from `Ptr` to the end of the
type.
* Added pointer casting support between any `Ptr` as long as the
`AddressSpace` is the same
* Disallow globallycoherent T* and coherent T*
* Disallow const T*, T const*, and const T*
* Fixed .natvis display of `ConstantValue` `ValOperandNode`
* Support generic resolution of type-casted integers
* Added `VariablePointer` emitting for spirv + other minor logic needed
for groupshared pointers
Breaking Changes:
* Anyone using the `AddressSpace` of `Ptr` will now have to account for
the `Access` argument
* we disallow various syntax paired with `Ptr` and `T*`
---------
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When `SIMPLE` type test is used with `-g[1-3]` option, the filecheck
pattern will most likely to match to the string itself on the embedded
source code rather than match to the emitted spirv-asm code.
This commit avoids the problem by removing the embedded source code.
This commit also provides an option to keep the embedded source code,
`-preserve-embedded-source`.
The source code removal is happening in two steps:
1. iterate all output lines and find SPIRV-ASM in the following pattern:
`%N = OpExtInst %void %M DebugSource %fileId %sourceId`. And then, store
the "%sourceId" value to identify which SPIRV instructions are for the
embedded source code.
2. iterate all output lines again to find the `%sourceId = OpString
"...."` and replace the whole string with the following string, ``` %1 =
OpString "// slang-test removed the embedded source // Use
`-preserve-embedded-source` to keep it explicitly " ```
This change revealed problems in the existing tests:
- tests/bugs/spirv-debug-info.slang : The expected text was missing and
it had to be added. The file also had Carrage-Return character on all
lines and the pre-commit git hook removed them.
- tests/spirv/debug-info.slang : the expected keyword DebugValue had to
change to DebugDeclare, because that's what we get with ToT.
- tests/spirv/debug-value-dynamic-index.slang : This test is currently
failing, and it will pass once DebugLocalVariable instruction missing
for parameter of the entry point function #7693 is resolved.
---------
Co-authored-by: slangbot <ellieh+slangbot@nvidia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#7929)
Fixes the Slang compiler internal error "subscript had no getter" when
reading from mesh shader output index arrays (e.g., `triangles[0].x`).
## Problem
The `OutputIndices` struct was missing a `ref` accessor in its
`__subscript` implementation, causing the compiler to fail when trying
to materialize subscript expressions as r-values.
## Solution
Added the missing `ref` accessor to `OutputIndices.__subscript` using
the `kIROp_MeshOutputRef` intrinsic operation, matching the pattern used
in `OutputVertices` and `OutputPrimitives`.
## Files Changed
- `source/slang/core.meta.slang` - Added missing `ref` accessor
- `tests/bugs/gh-7925.slang` - Test case to reproduce and verify the fix
Fixes #7925
Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Lujin Wang <lujinwangnv@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: slangbot <ellieh+slangbot@nvidia.com>
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
| |
Fixes #8185. The previous implementation is incorrect and basically only
works in the `x = 0` case. `delta` was the smallest possible positive
value representable as a float, but that's below the rounding error of
addition with almost all reasonably sized floats.
This fixed implementation is based on bit twiddling instead. I've
checked the float case against the C++ `nextafterf` with both a -inf ->
inf and inf -> -inf sweep, in addition to the test included in this PR.
|
| |
|
|
| |
Co-authored-by: Jay Kwak <82421531+jkwak-work@users.noreply.github.com>
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
| |
|
|
|
|
|
| |
Fixes #8116
---------
Co-authored-by: Jay Kwak <82421531+jkwak-work@users.noreply.github.com>
|
| |
|
|
|
|
|
|
| |
What is fixed:
Since we make `vk` tests compile as GLSL, we must use a capability that
specifies a GLSL equivalent.
If we do not do this, we will get an error since we are not specifying
GLSL capabilities (but are specifying a profile).
Since a profile is specified, we emit capability errors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
when we have `GetElementPtr -> load -> GetElement` in our use-chain, the
final `GetElement` may use the `load` as a `Index`, not a base.
This is a non-issue with `getFieldExtract` since a field is a StructKey.
We will still add this check to ensure no bugs down the line.
---------
Co-authored-by: Harsh Aggarwal <haaggarwal@nvidia.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: slangbot <ellieh+slangbot@nvidia.com>
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expressions in legacy mode (#7984)
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.
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 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 <ellieh+slangbot@nvidia.com>
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
Co-authored-by: aidanfnv <aidanf@nvidia.com>
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* fix bug
* fix test
* push test changs for clarity
* fix bug
* fix test
* push test changs for clarity
* test what fails
* remove redundant code
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix 7441: CUDA boolean vector layout to use 1-byte elements
Boolean vectors (bool1, bool2, bool3, bool4) were incorrectly implemented
as integer-based types using 4 bytes per element instead of actual 1-byte
boolean elements on CUDA targets.
Changes:
- Update CUDA prelude to define boolean vectors as structs with bool fields
instead of typedef aliases to integer vectors
- Implement CUDALayoutRulesImpl::GetVectorLayout to use 1-byte alignment
for boolean vectors, matching actual CUDA memory layout behavior
- Update make_bool functions to populate struct fields correctly
This ensures boolean vectors have the same memory layout as bool[4] arrays:
- bool1: 1 byte (was 4 bytes)
- bool2: 2 bytes (was 8 bytes)
- bool3: 3 bytes (was 12 bytes)
- bool4: 4 bytes (was 16 bytes)
Fixes memory layout mismatch between Slang reflection API and actual
CUDA compilation, achieving 75% memory savings for boolean vector usage.
* Fix CI issues -
Add and update associated functions and operators
* Make boolX same as uchar
* Use align construct on struct for boolX
* Improve Test case for robust alignment checks
* Formatting
* Disable selected slangpy tests
* add metal check which is slightly different than cuda
* Test-1
* Test-2
* Test-3
* Test-4
* ReflectionChange
* cleanup and update
* _slang_select with plain bool is needed for reverse-loop-checkpoint-test
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix static const variables without initializers causing internal errors
Add validation in SemanticsDeclHeaderVisitor::checkVarDeclCommon to detect static const variables without initializers and emit proper error diagnostics instead of allowing internal errors to escape during SPIR-V generation.
- Add new diagnostic (ID 31225) for static const variables without initializers
- Skip validation for extern static const variables
- Skip validation for interface member variables
- Add comprehensive test case covering various scenarios
Fixes #7989
Co-authored-by: ArielG-NV <ArielG-NV@users.noreply.github.com>
* clean up test and implementation
* format code (#7994)
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: ArielG-NV <ArielG-NV@users.noreply.github.com>
Co-authored-by: slangbot <ellieh+slangbot@nvidia.com>
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
| |
|
|
| |
statements (#7953)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Initial plan
* Initial investigation and plan for enum vertex output fix
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Fix compiler crash when enum is used as vertex output data
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Fix compiler crash when enum is used as vertex output data
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Address reviewer feedback: use SLANG_ASSERT and improve CHECK directives
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Initial plan
* Implement enum-based KnownBuiltin system to replace string comparisons
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Add test for enum-based KnownBuiltin system and verify functionality
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Implement enum-based KnownBuiltin system with direct integer values
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Fix IntVal access and update tests for new enum-based KnownBuiltin system
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Replace hardcoded KnownBuiltin integers with preprocessor enum syntax
- Updated all KnownBuiltin attributes to use $( (int)KnownBuiltinDeclName::EnumValue) syntax
- Added space between parentheses to avoid preprocessor bug: $( (int) instead of $((int)
- Updated both core.meta.slang and hlsl.meta.slang files
- Eliminates preprocessor-time integer conversion, baking enum values directly into meta files
- Maintains same functionality while using type-safe enum references
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Fix IDifferentiablePtr KnownBuiltin mapping regression
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Remove unused IDifferentiablePtrType enum case from KnownBuiltinDeclName
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Clean up temporary AST dump files from testing
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Replace hardcoded integer with descriptive constant in KnownBuiltin test
Replace the hardcoded [KnownBuiltin(0)] with a descriptive named constant
GEOMETRY_STREAM_APPEND_BUILTIN to improve code readability and maintainability.
The test now clearly indicates which builtin enum value is being tested.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Gangzheng Tong <gtong-nv@users.noreply.github.com>
---------
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: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Gangzheng Tong <gtong-nv@users.noreply.github.com>
Co-authored-by: Gangzheng Tong <tonggangzheng@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
* Fix language server crash.
* Fix tests.
* Fix.
* Revert changes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix segfault with Ptr<T> extension using 'This' type reference
Set LookupOptions::NoDeref when looking up target type members within
extension declarations to prevent automatic pointer dereferencing that
was causing breadcrumb handling issues and segfaults.
Fixes #7656
Co-authored-by: Yong He <csyonghe@users.noreply.github.com>
* Enhance test for ptr-extension-this-type to verify correctness with interpreter
- Changed function to return sizeof(This) - sizeof(Ptr<int>) + 1
- Modified test to use interpreter with filecheck to verify result equals 1
- Added main() function that calls the extension method and prints result
- Verifies that 'This' correctly refers to Ptr<int> in extension context
Co-authored-by: Yong He <csyonghe@users.noreply.github.com>
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Yong He <csyonghe@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Ensure generic constraints are checked before inner extension.
* Add warning for non-standard generic extension.
* Fix tests.
* Fix test.
* Ban interface types from equality constraints.
* Fix.
|
| |
|
|
|
| |
* Replace SLANG_ALIGN_OF with C++11 alignof
* Fix formatting (again)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add test for mixed use of uniform/ParameterBlock
Adds a test that uses the same struct as a parameter and as a
ParameterBlock.
* Fix for SPIRV block declaration issue
Fixes #7431
* Fix formatting
* Collect struct param usage in first pass
Reduces number of iterations over the entire program.
* more formatting fixes
* formatting
* Remove unused variable
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* emit var and hoist out OpSelect if Composite
* cleanup comment
* address review
check for version in spv context
use phi node instead of using var
move inst's using a list (not in-place modification)
* format code
---------
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functionality (#7067)
* 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 <yonghe@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Test for IFloat.scale usage
Test that using IFloat.scale doesn't cause an internal compiler error.
* Generic implementation of IFloat.scale()
Fixes #7156
* Implement IFloat.scale for matrix
Adds matrix implementation and test coverage.
* Avoid explicitly constructing a matrix
* Remove intrinsicOp from IFloat.scale impls
Updates IFloat.scale implementations:
- Remove __intrinsic_op($(kIROp_Mul)) since we're providing an
implementation
- Add [__unsafeForceInlineEarly] where missing
|
| |
|
|
|
|
|
|
|
| |
(#7499)
* Make phi elimination pass modify branches in-place
* Add test and fix formatting
* Avoid double removal of param insts
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add test case for missing import attribution
Add a test case that imports a non-existent file, followed by a valid
file. Tests for absence of a bug where slang reports existent files as
non-existent if they're imported after a non-existent file.
* Skip processing imports after errors
Skip processing additional imports after the first error. This
behavior is already observed in Linkage::loadSourceModuleImpl, but
since that happenes after import processing already started, a false
diagnostic gets generated for a missing import.
By hoisting this check out before the import is processed, the
diagnostic message for a missing file is no longer erroneously
generated.
Fixes #6453
* Revert "Skip processing imports after errors"
This reverts commit 6b2fef09782414de4c5e017c4ecb5f2affa0c199.
* Remove early abort of import processing
Partial revert of commit 04f1bad
Reverts an early return in Linkage::loadSourceModuleImpl() whenever any
error diagnostic message has already been generated. This was causing
earlier errors to prevent subsequent imports from succeeding, and was
misattributing them to a missing file.
Fixes #6453
---------
Co-authored-by: Yong He <yonghe@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix issue of missing scope for 'Differential' type
When we synthesize the struct decl for Differential type, we should
add the ownedScope for this decl, because the scope is used in lots
of locations in the following synthesized processes, e.g. constructor
synthesize. And that could cause surprising behavior, e.g. the 'this'
expression could access the members of parent struct decl.
Fix the issue by adding the scope. The containerDecl will be the
Differential struct decl itself, parent scope will be the parent struct.
* Add a unit-test
|
| |
|
|
|
| |
This PR replaces enable/disable style C function calls with C++ RAII style code.
In debug build, when an assertion failed in between enable and disable functions, an exception is thrown and the disable function is not called. RAII style code is safer for an exception
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add check for the variable requirement
This change adds the capability check for the variables requirement.
With this check, the shader
```
[require(cpp_cuda_glsl_hlsl_metal_spirv)]
Buffer<float> InputTyped;
[require(cpp_cuda_glsl_hlsl_metal_spirv)]
RWBuffer<float> OutputTyped;
```
will issue error if targeting to WSGL
e.g. `.\build\Debug\bin\slangc .\tests\wgsl_no_buffer.slang -o
wgsl_no_buffer.txt -target wgsl -entry Main -stage compute`
.\tests\wgsl_no_buffer.slang(2): error 36108: 'InputTyped' has dependencies that are not compatible on the required target 'wgsl'.
Buffer<float> InputTyped;
^~~~~~~~~~
.\tests\wgsl_no_buffer.slang(4): error 36108: 'OutputTyped' has dependencies that are not compatible on the required target 'wgsl'.
RWBuffer<float> OutputTyped;
^~~~~~~~~~~
Fixes #6304
* Add var capability tests
* Do capability checks for global var only
* Add inferredCapabilityRequirements to var capability check
* Add requirement to the intrinsic types Buffer/RWBuffer
* format code
* Update capabliity test
* use DefaultDataLayout as default data layout
* Use visitMemberExpr to check the capabilities
* Update the cap tests to match the error messages
* update test to use the ScalarDataLayout for hlsl target
* Update tests check condition to use error number only
* Add default push_constant data layout type
---------
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#7283)
* Ensure we do not have an initExpr on a var inside an InterfaceDecl
Ensure we do not have an initExpr on a var inside an InterfaceDecl. If we do, send an error.
Ensure the language server does not segfault with this error as per the issue.
* format code
* split tests
---------
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes issue #6898
The -emit-spirv-via-glsl slang-test option has been broken for
some amount of time. Tests that were using it were operating as
if using -emit-spirv-directly, leading to many duplicated tests.
After fixing the test option, there were an number of errors that
appeared as a result.
This change fixes the broken test option and the resulting test
errors. Some of the test errors revealed some legitimate issues,
such as:
-The GLSL bitCount instrinsic only supports 32-bit integers and
requires emulation for other bit widths.
-Emitting GLSL 8-bit and 16-bit glsl integer types did not emit
the proper extension requirements
-Emitting GLSL and casting for 16-bit integers was missing a
closing parenthesis.
-Missing profile for GL_EXT_shader_explicit_arithmetic_types
-Missing toType cases for UInt8/Int8 for the kIROp_BitCast case
in tryEmitInstExprImpl.
|
| | |
|
| |
|
|
|
|
|
| |
Problem:
* Infering type with `let` while using constant-foldable object's means we run in a circular loop of `ensureDecl`.
Changes:
* If we constant-fold we effectively are ready to check definition. If we are not a constant to fold, we run `setCheckState` after anyways.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix using local constants in switch cases
* Add test
* format code
* Always lower switch cases with exprVal
* Fix formatting
---------
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
Co-authored-by: Yong He <yonghe@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add IREnumType to distinguish enums from ints and each other
* Add issue example as test
* format code
* Add expected test output
* Fix peephole optimization hanging
No idea why this PR triggered this, but there seems to have been a clear bug
here anyway, so may just as well fix it now.
* Move enum lowering later
* Add linkage decoration to enum type
* Use filecheck-buffer instead of expected.txt
* Fix comment
* Make enum casts actually use IR enum casts
They were all BuiltinCasts by accident
* Lower enum type before VM
* Deal with rate-qualified types in enum cast
* Allow any value marshalling for enum types
* Handle new enum instructions in a couple more switches
* Fix formatting
---------
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
| |
|
|
|
|
|
| |
* Support `this` use of `IRMeshOutputRef`
* Fix SPIR-V val error
There was a type mismatch causing a spir-v failiure: `store(var, var)` instead of `store(var, load(var))`
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Work on #6892
The function `tryInferLoopMaxIterations` in `slang-check-stmt.cpp` was
doing:
auto litExpr = m_astBuilder->create<LiteralExpr>();
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<IntegerLiteralExpr>();
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* update slang-rhi submodule
* slang-rhi API changes
* disable agility sdk
* fix texture creation
* update formats in tests
* Extent3D rename
* use 1 mip level for 1D textures for Metal
* fix texture upload
* update to latest slang-rhi
* update slang-rhi
* format code
* update slang-rhi
* do not run texture-intrinsics test on metal
* update slang-rhi
* deal with failing tests
* fix more tests
* update slang-rhi
---------
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
Co-authored-by: Simon Kallweit <simon.kallweit@gmail.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Close #6589.
In PR #6487, we support partial specialization. However there is a corner case we didn't handle correctly.
For the IR like this:
%val: specialize(...) = some inst;
%arg1: specialize(...) = makeExistential(%val, ...);
%arg2: %SomeConcreteType: load(...);
call func(%arg1, %arg2);
when we specialize the call func instruct, we will also specialize the function parameters.
On our existing logic, when we find an argument is a makeExistential, we will always extract the existential value, and use its type as the new parameter.
But in this case, %arg1 is not fully specialized yet, so it's type will still be a specialize. In this case, we will change the function's first parameter from an existential type to a specialize. This will result in that we lose the chance to specialize the first argument in the next iteration, because the first parameter of this function is not an existential type any more.
The reason behind this is that we should always keep specializing the arguments and parameters at the same time.
So this PR just does a check before specializing the parameters that if the argument cannot be fully specialized, we won't specialize the parameter this early. Instead, we will wait for the next iteration until the argument can be specialized.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix matrix division by scalar for Metal and WGSL targets
* Add tests
* Minor fix
* Fix compilation error
* Convert to multiplication for WGSL
* Minor cleanup
---------
Co-authored-by: Yong He <yonghe@outlook.com>
|
| |
|
|
|
|
|
|
| |
Fixes #6171
This commit adds logic for reporting double support
to the d3d11 backend, for running tests on GPUs that
do not support D3D11_FEATURE_DOUBLES, and add checks
for that support to tests that require the feature.
|