Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2025-06-12T14:57:42+00:00 2025-06-12T14:57:42+00:00 Yong He yonghe@outlook.com 2025-06-12T14:57:42+00:00 urn:sha1:4ae6e9d8b7790d827ca9edd729ad94f38a0c73de * Diagnose on use of struct inheritance. * fix test. * Fix tests. * fix. --------- Co-authored-by: ArielG-NV <159081215+ArielG-NV@users.noreply.github.com> 2025-02-05T18:37:03+00:00 kaizhangNV 149626564+kaizhangNV@users.noreply.github.com 2025-02-05T18:37:03+00:00 urn:sha1:9ec6b91686b651d959fd9ffbec283845bd725dd6 * SP004: implement initialize list translation to ctor - We synthesize a member-wise constructor for each struct follow the rules described in SP004. - Add logic to translate the initialize list to constructor invoke - Add cuda-host decoration for the synthesized constructor - Remove the default constructor when we have a valid member init constructor - Disable -zero-initialize option, will re-implement it in followup (#6109). - Fix the overload lookup issue When creating invoke expression for ctor, we need to call ResolveInvoke() to find us the best candidates, however the existing lookup logic could find us the base constructor for child struct, we should eliminate this case by providing the LookupOptions::IgnoreInheritance to lookup, this requires us to create a subcontext on SemanticsVisitor to indicate that we only want to use this option on looking the constructor. - Do not implicit initialize a struct that doesn't have explicit default constructor. Co-authored-by: slangbot <186143334+slangbot@users.noreply.github.com> 2024-11-06T19:21:53+00:00 Yong He yonghe@outlook.com 2024-11-06T19:21:53+00:00 urn:sha1:2533125cb7c673b313195e1d8bc6066b253d95ae * Fix WGSL parameter block binding. * Re-enable tests. * Update failure list. * Fix entrypoint parameters. * Update tests. * Enable stat-var test. 2024-10-15T16:11:53+00:00 Anders Leino aleino@nvidia.com 2024-10-15T16:11:53+00:00 urn:sha1:9e3b0367cfd63f21a0519b61b6fd13e94dac1c51 2024-06-10T20:28:36+00:00 skallweitNV 64953474+skallweitNV@users.noreply.github.com 2024-06-10T20:28:36+00:00 urn:sha1:712ce653d4c3d7284dd71389f31540d0da7f144e 2024-06-07T07:28:16+00:00 skallweitNV 64953474+skallweitNV@users.noreply.github.com 2024-06-07T07:28:16+00:00 urn:sha1:004fe27a52b7952111ad7e749397aeff499de7ed 2023-12-06T20:05:07+00:00 Yong He yonghe@outlook.com 2023-12-06T20:05:07+00:00 urn:sha1:11111e5733b189127dc2c4934d67693b9bc6e764 * Support visibility control and default to `internal`. * Fix wip. * Fixes. * Fix. * Fix test. * Add legacy language detection and compatibility for existing code. * Add doc. --------- Co-authored-by: Yong He <yhe@nvidia.com> 2022-08-18T06:08:34+00:00 Yong He yonghe@outlook.com 2022-08-18T06:08:34+00:00 urn:sha1:adaea0e993fd8db351b5dad92802e47ed6d0ec77 * Warning on bool to float conversion. * Fix test cases. * Improve. * LanguageServer: don't show constant value for non constant variables. * Fix tests. * Fix warnings in tests. Co-authored-by: Yong He <yhe@nvidia.com> 2021-05-27T22:05:34+00:00 T. Foley tfoleyNV@users.noreply.github.com 2021-05-27T22:05:34+00:00 urn:sha1:89faa8a7d9b441b5dd92eec5fcf362eb3f38fa2b If the user has a derived `struct` type: ```hlsl struct Base { int b = 1; } struct Derived : Base { int d = 2; } ``` Then it is still reasonable for them to want to use initializer lists when declaring variables using the `Derived` type: ```hlsl Derived x = {}; Derived y = { 7, 8 }; ``` This change implements two missing pieces of functionality in the Slang compiler to allow this case: * First, when the front-end semantic checks are applied to an initializer list, if the type being initialized is a derived `struct` type it always expects to find initialization arguments for its base type before those for its fields. * Second, when lowering an initializer-list expression from the AST to the IR, the compiler expects the first argument in the list to be the initial value for the base field (if any). This also applies to default-initialization of fields/variables. This change slightly entangles front-end logic with the logic for how struct inheritance is lowered to the IR, but the behavior is unlikely to confuse users who expect C++-like layout. It is worth noting that with this change it should be possible to initialize the base type using either a nested initializer list or flat arguments: ```hlsl struct BigBase { int x; int y; int z; } struct BigDerived : BigBase { int w; } BigDerived a = { {1,2,3}, 4 }; BigDerived b = { 1, 2, 3, 4 }; ``` This behavior should Just Work because of the existing C-like rules for initializer lists where an aggregate can be initialized by either a `{}`-enclosed block or distinct values for its leaf fields. 2021-05-27T20:40:17+00:00 T. Foley tfoleyNV@users.noreply.github.com 2021-05-27T20:40:17+00:00 urn:sha1:63dcc7acf4784d95407866730a70f5d37d391b88 During lowering from AST to IR, the Slang compiler translates code that uses `struct` inheritance: ```hlsl struct Base { int a; } struct Derived : Base {} ``` into code where the inheritance relationship is "witnessed" by a simple field: ```hlsl struct Base { int a; } struct Derived { Base __anonymous_field__; } ``` The underlying bug here is that the `__anonymous_field__` that the compiler generated during IR lowering was not being given any linkage decorations (no mangled name). As a result, if multiple separately-compiled modules all access that field they could disagree on its identity as an IR instruction. This could lead to output code being generated where the declaration of `__anonymous_field__` uses one IR instruction, but accesses use another. This change includes a fix for the issue, and a test that serves as a reproducer for the original problem.