| Age | Commit message (Collapse) | Author |
|---|
|
Generate a diagnostic warning whenever unsupported modifiers (keywords,
attributes) are found on entry point parameters. These have been
silently ignored up until now, with the parser accepting them but Slang
not actually doing anything with them.
Fixes #7151
---------
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
|
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>
|
|
When slang detects assignment to a mesh output reference on metal,
generate a diagnostic message. (Metal mesh shader outputs must be
assigned via 'set' instead of 'ref'.)
Fixes #7498
|
|
requirements (#7269)
## Summary
This PR enhances constexpr validation by adding proper error checking
when function arguments cannot satisfy constexpr parameter requirements,
addressing issue #6370.
## Problem
Previously, when a function declared constexpr parameters, the compiler
would attempt to propagate constexpr-ness to the call site arguments,
but there was insufficient validation and error reporting when this
propagation failed. This could lead silent failures where constexpr
requirements weren't properly enforced
## Solution
This PR adds checks that:
1. **Validates constexpr arguments**: When a function parameter is
marked as `constexpr`, the compiler now explicitly checks that the
corresponding argument can be marked as `constexpr`
2. **Issues clear compilation errors**: added
`Diagnostics::argIsNotConstexpr`)
3. **Handles both call scenarios**: The validation works for both:
- Direct function calls with IR-level function definitions
- Calls to function from external modules
Fixes #6370
---------
Co-authored-by: slangbot <ellieh+slangbot@nvidia.com>
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
|
This change relaxes a previous restriction on link-time types and
constants, so that we now allow them to be used to define shader
parameters.
Doing so will result in a parameter layout that is incomplete prior to
linking. The PR added a test to call the reflection API on a fully
linked program and ensure that we can report correct binding info.
|
|
The code int x4 = 0xFFFFFFFFFFFFFFFF previously did not produce a
warning due to the value being too large for the type. This patch now
checks for this and similar issues during parsing.
|
|
closes https://github.com/shader-slang/slang/issues/3313
|
|
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>
|
|
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>
|
|
Closes https://github.com/shader-slang/slang/issues/5750
|
|
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>
|
|
* Initial plan
* Fix pragma warning not working with multifile modules
- Check if DiagnosticSink already has a WarningStateTracker before creating new one
- This preserves pragma warning state across __include'd files
- Add regression tests for multifile pragma warnings
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Add additional test cases for nested pragma warnings
- Test nested __include scenarios with pragma warning directives
- Verify pragma warnings work correctly with multiple levels of includes
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>
Co-authored-by: Yong He <yonghe@outlook.com>
|
|
|
|
* Show signature help on generic parameters.
* Fix.
* Update tests.
* slang-test: make vvl error go through stderr.
* update slang-rhi
* Update slang-rhi
|
|
Closes https://github.com/shader-slang/slang/issues/3386
|
|
* Improve diagnostics over ambiguous references.
* Fix.
* Remove files.
* Fix some optix hitobject intrinsics.
* Fix some hitobject intrinsics for optix.
* Fix.
* update rhi
* revert slang-rhi
* Update slang-rhi
|
|
* Initial plan
* Add improved diagnostic for interface return type mismatches
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Complete fix for interface return type mismatch error reporting
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Move diagnostic to synthesis phase for better interface return type mismatch errors
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Remove extraneous test file and update .gitignore
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Add diagnostic test for interface return type mismatch and apply formatting
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Address feedback: restore whitespace and use filecheck for diagnostic test
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Fix logic error in return type mismatch detection
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Remove unnecessary flag by using out parameter for diagnostic tracking
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Refactor witness synthesis failure reporting to use structured approach
Replace ad-hoc `outSpecificDiagnosticEmitted` parameter with `WitnessSynthesisFailureReason` enum and `MethodWitnessSynthesisFailureDetails` struct as requested in code review. This provides:
- Clear taxonomy of failure reasons (General, MethodResultTypeMismatch, MethodParameterMismatch)
- Centralized diagnostic emission in findWitnessForInterfaceRequirement
- Better extensibility for future failure types
- Improved maintainability by removing state tracking flags
The return type mismatch diagnostic continues to work correctly, showing error 38106 with precise location information.
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Remove unused MethodParameterMismatch enum and duplicate code
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Remove redundant requiredMethod field from MethodWitnessSynthesisFailureDetails
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Address feedback: add outFailureDetails guard and remove unnecessary hasReturnTypeError variable
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Fix regression: restore original diagnostic message for mutating method mismatch
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Fix.
* Fix.
* Remove `innerSink`.
* Print candidates considered for interface match upon error.
* Fix tests.
---------
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 <yonghe@outlook.com>
|
|
* Fix visibility of synthesized `Differential` typedefs.
* Delete incorrect test.
|
|
* Initial plan
* Fix segfault when using -separate-debug-info with unsupported targets
Add validation to emit a diagnostic error when -separate-debug-info is used
with targets other than SPIR-V binary. Previously, this would cause a segfault
because the separate debug info logic is only implemented for SPIR-V targets.
Changes:
- Added new diagnostic error (ID 18) for unsupported separate debug info usage
- Added validation in OptionsParser::_parse() to check target compatibility
- Created test cases for HLSL and GLSL targets to verify the fix
- Updated error message to clarify only SPIR-V binary targets are supported
The fix prevents segfaults and provides clear feedback to users about
target limitations for the -separate-debug-info option.
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Address feedback: fix segfault properly instead of preventing it
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>
|
|
* Fix crash when private ctor is used for coercion.
* Fix tests.
* Fix.
* Fix test error.
|
|
* Initial plan
* Implement out-of-bounds array access checking
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Add tests and format code for array bounds checking
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Move checkForOutOfBoundAccess to separate file and refactor using InstPassBase
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Optimize out-of-bounds checker to use single IR traversal
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Fix DiagnosticSink forward declaration from struct to class
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Update 0-array-1 test to use runtime indices to avoid bounds checking diagnostic
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Use SV_DispatchThreadID for truly runtime array access in 0-array-1 test
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
* Fix GLSL global const diagnostic regression - add test exclusion for GLSL module
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>
|
|
* Add diagnostic for const/uniform global variables with initializers
Global const and uniform variables without the static modifier are
treated as uniform parameters in HLSL, which cannot have default values.
This change adds error 31224 to catch this case early and provide clear
guidance to users.
Fixes #7701
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Yong He <csyonghe@users.noreply.github.com>
* Add test case for global const/uniform variable diagnostic
Add test for diagnostic 31224 which catches global const and uniform
variables with initializers that aren't declared static. The test
verifies both error cases and valid cases to ensure the diagnostic
works correctly.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Yong He <csyonghe@users.noreply.github.com>
* Fix failing tests due to new global const diagnostic
Add 'static' keyword to global const variables with initializers
to resolve diagnostic 31224: "global const variable with initializer
must be declared static"
Co-authored-by: Jay Kwak <jkwak-work@users.noreply.github.com>
* Allow specialization constants with initializers without static
- Modified diagnostic logic in slang-check-decl.cpp to allow specialization
constants (SpecializationConstantAttribute and VkConstantIdAttribute) to
have initializers without requiring the static keyword
- Updated 8 SPIRV test files to remove unnecessary static keywords from
specialization constant declarations
- Enhanced diagnostic test case to include specialization constant examples
- All tests passing with the new behavior
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Yong He <csyonghe@users.noreply.github.com>
* format code (#7765)
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
* Remove static keyword from specialization constants and add comprehensive test cases
- Remove static from specialization constants in test files as they are semantically meaningless
- Update tests to use existing diagnostic 31219 for static specialization constant errors
- Add comprehensive test cases that verify the error occurs when static is used with specialization constants
- Fixes suggested in PR review to make static specialization constants an error
Co-authored-by: ArielG-NV <ArielG-NV@users.noreply.github.com>
* Add error for static specialization constants
Static specialization constants are semantically meaningless and should
produce an error. This change adds logic to trigger diagnostic 31219
when both 'static' and specialization constant attributes are present.
The existing diagnostic 31219 'push or specialization constants cannot
be static' is now correctly triggered for:
- [SpecializationConstant] static const variables
- [vk::constant_id] static const variables
Co-authored-by: ArielG-NV <ArielG-NV@users.noreply.github.com>
* Update source/slang/slang-check-decl.cpp
* Update tests/glsl/compute-shader-layout-id.slang
* Update tests/glsl/compute-shader-layout-id.slang
* Fix test case Claude broke
* Update global-uniform.slang
* Update global-uniform.slang.expected
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Yong He <csyonghe@users.noreply.github.com>
Co-authored-by: ArielG-NV <159081215+ArielG-NV@users.noreply.github.com>
Co-authored-by: Jay Kwak <jkwak-work@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: ArielG-NV <ArielG-NV@users.noreply.github.com>
|
|
(#7737)
* Initial plan
* Add validation and clear error message for float generic parameters
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>
|
|
* Emit special diagnostic for invalid pointer taking operations
* Update source/slang/slang-diagnostic-defs.h
Co-authored-by: ArielG-NV <159081215+ArielG-NV@users.noreply.github.com>
* Add OperatorAddressOf KnownBuiltin modifier
* update error message for non-l-value assignment
* update the diagnostics in the tests
* Use enum based KnownBuiltinDeclName
* format code (#7772)
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
---------
Co-authored-by: ArielG-NV <159081215+ArielG-NV@users.noreply.github.com>
Co-authored-by: slangbot <ellieh+slangbot@nvidia.com>
Co-authored-by: slangbot <186143334+slangbot@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.
|
|
* Initial plan
* Add diagnostic for unreferenced generic parameters in extensions
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Use GenericTypeParamDeclBase and eliminate intermediate list
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Update test to use filecheck format for better verification
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Update extension validation to use getMembersOfType for better constraint collection
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Add temporary workaround for inheritance constraints but issue persists
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Fix inheritance constraint validation by moving to SemanticsDeclConformancesVisitor
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Fix inheritance constraint validation by removing inheritance declaration checks
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Move extension generic parameter validation back to SemanticsDeclBasesVisitor
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Fix test.
* format code (#7671)
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
* Fix and update.
* Refine fix.
---------
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 <yonghe@outlook.com>
Co-authored-by: slangbot <ellieh+slangbot@nvidia.com>
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
|
close #6286.
This PR is to improve the diagnostics for no_diff usage.
In a differentiable function, any calls to a non-diff function with constant arguments should not require no_diff attribute.
This PR adds this extra check at `checkAutoDiffUsages` where it checks the differentiability on IR.
In a differentiable method, we will force to use `[NoDiffThis]` attribute if there is access to non-differentiable `This` type. Once this access is detected we will report a warning to bring users attention that this access won't generate any derivative, they have to use `[NoDiffThis]` to suppress that warning.
This PR adds this check at type checking stage, because it's the easiest way to find out all the `This` accesses.
|
|
* Add error for forward references in generic constraints
Change addresses issue #6545.
The slang compiler's type checker is unable to support cases where
a generic type parameter is referenced as a constraint before it is
declared. For example code like:
````
interface IFoo<T : IFloat>
{
}
void bar<Foo : IFoo<T>, T : IFloat>()
{
}
````
Is not supported, but will currently report a generic error like,
"(0): error 99999: Slang compilation aborted due to an exception
of class Slang::InternalError: unexpected: generic type constraint
during lowering"
This change adds a new check for this kind of code and reports an
error like,
"error 30117: generic constraint for parameter 'Foo' references type
parameter 'T' before it is declared"
when detected. Basic testing of this error is also added in a new
diagnostic test.
* Add error for forward refs in generic constiants update 1
* Add error for forward refs in generic constraints update 2
Revised algo in checkForwardReferencesInGenericConstraint to run
in O(n) instead of the previous O(n^2) using HashSets.
* Add error for forward refs in generic constraints update 3
-Update logic adding referenced decl's in collectReferencedDecls.
-Simplified error string logic.
* Add error for forward refs in generic constraints update 4
-Declare collectReferencedDecls in slang-check.h such that it can
be used as a general utility function.
* format code
---------
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
|
* Initial plan
* Fix spurious vk::binding warnings when attribute is present
- Modified _maybeDiagnoseMissingVulkanLayoutModifier to check for GLSLBindingAttribute before warning
- Changed function to return bool indicating if warning was actually issued
- Updated call sites to properly track warning state to reduce duplicates
- Tested fix resolves the issue while preserving correct warnings when needed
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Add test case for vk::binding spurious warning fix
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Update test to use filecheck format as requested
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Remove full file path from CHECK directives as requested
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Fix code formatting with clang-format
Co-authored-by: csyonghe <2652293+csyonghe@users.noreply.github.com>
* Fix behavioral regression in vk-bindings test caused by warning flag logic
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>
Co-authored-by: Yong He <yonghe@outlook.com>
|
|
* Defer immutable buffer loads when emitting spirv.
* Fix.
* Fix.
* Fix.
* Fix tests.
* Fix test.
|
|
* Fix false negative result for CUDA with recent versions
From CUDA version 12.8 and above, nvrtc returns an exit code treated as
an error. Some of slang-test test cases had to change from TEST to
DIAGONOSTIC_TEST to handle it properly.
|
|
* Add additional completion keywords.
* LanguageServer: Enhance auto completion for `override`.
|
|
* Require `override` keyword for overriding default interface methods.
* Update doc.
* Fix test.
|
|
* Diagnose on use of struct inheritance.
* fix test.
* Fix tests.
* fix.
---------
Co-authored-by: ArielG-NV <159081215+ArielG-NV@users.noreply.github.com>
|
|
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
|
|
* Fix#6993 - Emit Diagnostic Warning and Fix SIGSEGV
* Update external/slang-rhi submodule
* Add checks for valid stage names for paq in SemanticsVisitor check
* format code
---------
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
Co-authored-by: Ellie Hermaszewska <ellieh@nvidia.com>
|
|
* Add legalization for 0-sized arrays.
* Allow 0-sized arrays in the front-end.
* More tests.
* Add `Conditional<T, hasValue>` type to core module.
* Update toc.
* Fix wording.
* Update test.
|
|
|
|
Fixes #6987
|
|
* Implement default initializer list for C-Style type member
Close #6189.
Previsouly, for the C-Style member in a struct, if it doesn't have any initialize
expression, when we synthesize the ctor, we will not associate the
default value for the parameter corresponding to that member.
This bring some trouble that existing slang users has to add '= {}' to
every struct fields in order to make all the parameters in the synthesized ctor having
a default value, so people can still use `Struct a = {}` to create a
struct.
To make this use case convenience, we will automatically associated a
'= {}' as the default value for this case.
This PR also add support for empty initializing link-time sized vector/matrix by "= {}".
In addition, this PR also fix a bug in auto diff where we should not report error when proccessing
transpose on an empty struct.
|
|
The user can explicitly use Vulkan memory model, or it will be
automatically used when cooperative-matrix is used.
When vulkan memory model is used, two keywords, "Coherent" and
"Volatile", are not allowed.
There are many differences regarding atomic and texture but
this PR has changes limited to support `globallycoherent`
keyword. When variables with `globallycoherent` is used with `OpLoad`, it
will use additional options, `MakePointerAvailable|NonPrivatePointer`,
that will provide the same effect. For `OpStore`, it will use
`MakePointerVisible|NonPrivatePointer`.
|
|
* Add checking for hlsl register semantic.
* Fix.
* Fix test.
* Fix switch error.
* Fix tests.
|
|
* Rename 'main' on some backednds
Fixes #5542
Some backends like cuda, metal, cpu do not allow 'main' as the entry
point. This commit adds a new warning that is emitted when a program
uses main as the entry point. In addition to emitting the warning, it
internally renames the entry point to "main_". It also adds a test to
check these for the three backends.
* format code
* move test to diagnostics
* rename test to diagnostic
* generate unique name
---------
Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com>
|
|
* Error out on invalid vector sizes
* Remove unnecessary include
* Fix incorrect assert
* Add test
|
|
Fixes #7049
The root cause of the problem in #7049 is simply that newer NVRTC versions produce a warning when asked to generate code for older CUDA SM versions, and the default that Slang was requesting compilation for was old enough to trigger that warning, and thus trip up the test case (which only looks at the first diagnostic produced by the downstream compiler).
Superficially, the fix was easy: change the test case in question (`tests/diagnostics/local-line.slang`) to request `-capability cuda_sm_8_0`, the minimum version supported by current NVRTC.
Unfortunately, the simple fix required some other fixes in order to actually work.
The capability system includes capability names of the form `cuda_sm_*_*`, but specifying such a capability had *no* impact on the CUDA SM version passed in when invoking NVRTC.
Instead, only the CUDA SM versions requested in the implementation of intrinsics in the core module were affecting the version number passed down.
This change adds logic to `slang-compiler.cpp` to take explicitly requested capabilities into account when inferring the CUDA SM version to be passed downstream.
A more complete fix would also add similar logic for all the other targets.
Unfortunately... yet again... that fix wasn't enough to make things work as expect.
Now I had the problem that requesting `-capability cuda_sm_8_0` was actually causing the NVRTC invocation to request CUDA SM version **9.0**!
The underlying problem *there* was that the `slang-capabilities.capdef` file has defined certain capability names in a way that implies atomic capabilities much higher than one would expect.
E.g., the `cuda_sm_8_0` alias was including HLSL `sm_5_0`, but then `sm_5_0` in turn included `_cuda_sm_9_0`.
The fix, for now, is to change the definitions in `slang-capabilities.capdef` to not have the counter-intuitive definitions for `cuda_sm_*_*`.
With this set of fixes, the test failure in the original bug report no longer occurs.
The work that went into this change suggests several larger-scope fixes that would be good to pursue:
* Ideally the capability definitions would have some sort of validation checking to make sure that counter-intuitive results like `cuda_sm_8_0` requesting CUDA SM 9.0 do not occur.
* The translation of capabilities over to version numbers for a downstream compiler should be expanded to cover other targets, and not just CUDA. It might be better/simpler to just pass the capabilities themselves to the downstream compiler, since it is possible that a downstream compiler could have more fine-grained enable/disable options than a simple version number.
* The entire approach to computing version numbers required for downstream compilation should be cleaned up so that we don't have this duplication between the capabilities that represent those versions and separate syntactic constructs that are used to "request" those versions as part of code generation.
* We are very much at the point where we should consider dropping the current behavior where a profile name or capability like `sm_5_0`, that is specific to a single target or a subset of targets, also implies a set of comparable capabilities for other targets.
|
|
* Fix #6544: Properly format nested type names in extensions
Modify DeclRefBase::toText to properly handle types defined
in extensions by qualifying them with their parent type name.
This ensures getFullName() returns the full name like
'FullPrecisionOptimizer<half>.State' instead of just '.State'.
Also handle other nested types in structs/classes similarly.
* Update extension reflection handling - with generics args and namespaces
- stopping namespace inclusion for extension members
- Update to use getTargetType() to handle the generic arguments
- update test cases
* Simplify code to remove using parentDecl
|
|
* Initial implementation for SPIRV, GLSL and Metal
* test add bool test
* Fix and improve subgroup rotate tests
* Add proper GLSL extensions and proper Metal type checking
* Clean up tests and add diagnostics test for subgroup type for Metal
* Update wave-intrinsics docs
|
|
* Add struct member offset qualifier for SPIRV
* Implement for GLSL target and add tests
* clean up
* fix formatting
* fix typo
* renamed GLSLStructOffset to VkStructOffset and added emit-spirv-via-glsl test case
|
|
* 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>
|
