Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2025-06-09T18:22:51+00:00 2025-06-09T18:22:51+00:00 Theresa Foley 10618364+tangent-vector@users.noreply.github.com 2025-06-09T18:22:51+00:00 urn:sha1:bfae49d853e0f9b6f9de495b13bcd1642ca4a285 Most of what this change does is straightforward: take all the places in the code that used to operate directly on `ContainerDecl::members` and related fields, and instead have them call into a smaller set of accessor methods defined on `ContainerDecl`. The primary motivation for making this change is that in order to implement on-demand loading of members from serialized AST modules, we need a way to identify and intercept the "demand" for those members. On-demand loading benefits from having all accesses to the members of a `ContainerDecl` be as narrow as possible. If a part of the code only need a member at a specific index, it should say so. If it only needs access to members with a specific name, or a given subclass of `Decl`, then it should say so. A secondary motivation for this change is that there have recently been several changes that added complexity and special cases by introducing code that operated on (and *mutated*) the member list of a container decl in ways that the existing code had never done before. Any code that mutates the member list of a `ContainerDecl` needs to be sure to not disrupt the invariants that the lookup acceleration structures currently rely on. One of the recent changes added a declaration-to-index map to the set of acceleration structures (with different validation/invalidation behavior than the others...) while other recent changes would remove or insert declarations in ways that could change the indices of other declarations in the same container. It is not clear if any of these pieces of code were aware of the others, and the invariants that might be expected or broken along the way. This change bottlenecks the vast majority of accesses to the members of a `ContainerDecl` through the following operations: * Getting a `List` of all of the direct member declarations of a container * Get the number of direct member declarations, and accessing them by index. * Looking up the list of direct member declarations with a given name. * Adding a new direct member declaration to the end of the list. Some other operations are layered on top of those (e.g., getting a list of all the direct member declarations of a given C++ class). These layered operations are still centralized on the `ContainerDecl`, with the intention that we *can* change them to be non-layered implementations if we ever need to for performance (e.g., by building a lookup structure for finding member declarations by their type). The exceptional cases of access/mutation on the direct members of a `ContainerDecl` have also been encapsulated, but rather than expose what would risk appearing like general-purpose accessors (e.g., `removeDecl(d)`, `setDecl(index)`, etc.), these operations have been explicitly named after the specific use case that they serve in the codebase today, to discourage others from using them for more kinds of operations we'd rather not support. These operations have also been given parameter signatures that match their use cases, to make it so that even somebody determined to abuse them would have to invent suitable arguments out of thin air. In the case of the declaration-to-index mapping, this change eliminates that acceleration structure, in favor or slightly more complicated (and possibly inefficient, yes) code at the use site. Over time, it would be good to closely scrutinize each of the use cases that requires more complicated interaction with the members of a `ContainerDecl`, to see whether any of them can be reframed in terms of the more basic operations, or if there is some clean abstraction we can introduce to make operations that mutate the member list feel like... hacky. 2025-02-05T20:32:56+00:00 Yong He yonghe@outlook.com 2025-02-05T20:32:56+00:00 urn:sha1:7911c9437333692db275d2dff41264f4c8023be8 * Use two-stage parsing to disambiguate generic app and comparison. * Typo fix. * Update doc. 2024-12-12T00:58:13+00:00 Yong He yonghe@outlook.com 2024-12-12T00:58:13+00:00 urn:sha1:2999cb72a297152699a099b0f7762143dcc9a055 2024-10-29T06:49:26+00:00 Ellie Hermaszewska ellieh@nvidia.com 2024-10-29T06:49:26+00:00 urn:sha1:f65d756bff8d4c5cbc15bd0322a2ae8e6b896a21 * format * Minor test fixes * enable checking cpp format in ci 2024-09-05T18:25:09+00:00 Yong He yonghe@outlook.com 2024-09-05T18:25:09+00:00 urn:sha1:e5ead400647c382c9d107e568b6374915c3702ae 2024-08-13T03:53:03+00:00 Yong He yonghe@outlook.com 2024-08-13T03:53:03+00:00 urn:sha1:b390566b55700582321b09b72c726b8dff9bd819 * Support unicode identifier names. * Fix. * Fix language server. * Fix build errors. * Fix. * Fix offset translation in language server. 2024-07-09T02:33:51+00:00 Yong He yonghe@outlook.com 2024-07-09T02:33:51+00:00 urn:sha1:a453fadfb373499f08779dd7df8f2347d292fd91 2023-04-27T04:36:59+00:00 Ellie Hermaszewska ellieh@nvidia.com 2023-04-27T04:36:59+00:00 urn:sha1:3acbe8145c60f4d1e7a180b4602a94269a489df5 2023-04-25T14:43:29+00:00 jsmall-nvidia jsmall@nvidia.com 2023-04-25T14:43:29+00:00 urn:sha1:7b7c095b37e85ca3a8f55eff1c3d9643d467b8e0 * #include an absolute path didn't work - because paths were taken to always be relative. * WIP lowerCamel Dictionary. * WIP more lowerCamel fixes for Dictionary. * Add/Remove/Clear * GetValue/Contains * Fix tabs in dictionary. Count -> getCount * Fix fields with caps. * Key -> key Value -> value Use m_ for members where appropriate. Use lowerCamel in linked list. * Some small fixes/improvements to Dictionary. * Kick CI. 2022-06-16T08:50:43+00:00 Yong He yonghe@outlook.com 2022-06-16T08:50:43+00:00 urn:sha1:241def9c7619c437aad1bb620be8891e61707d8d * Language Server: Document Symbol outline. * Fix highlighting of extension decls. Co-authored-by: Yong He <yhe@nvidia.com>