Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2024-11-29T07:02:19+00:00 2024-11-29T07:02:19+00:00 Bruce Mitchener bruce.mitchener@gmail.com 2024-11-29T07:02:19+00:00 urn:sha1:c3557978cf0184aaf75c27c309bc87e84fd6ab79 Co-authored-by: Ellie Hermaszewska <ellieh@nvidia.com> 2024-06-10T12:15:02+00:00 Anders Leino aleino@nvidia.com 2024-06-10T12:15:02+00:00 urn:sha1:0974463daf0982626cb2b8c8bb6f494f3e6c9e52 2024-04-10T20:38:50+00:00 Yong He yonghe@outlook.com 2024-04-10T20:38:50+00:00 urn:sha1:ee9d398ebfc7c67205a8d5c91834ae4882d0dc9b 2019-02-02T16:58:54+00:00 jsmall-nvidia jsmall@nvidia.com 2019-02-02T16:58:54+00:00 urn:sha1:3726194fbe3da234eb30b6371e5b4ab1ea388f93 * Replace dynamicCast with as where does not change behavior (ie not Type derived). Use free function where scoping is clear. * Replace uses of dynamicCast with as when there is no difference in behavior. * Remove the IsXXXX methods from Type. * Don't have separate smart pointer to store canonicalType on Type. * Simplify Slang.FilteredMemberRefList.Adjust, such does the cast directly. * Use free as where appropriate. * Use free function version of casts where appropriate. * Fix text in casting.md * Fix typos in decl-refs.md * Remove the uses of free function as on RefDecl. Add 'canAs' to RefDecl as a way to test if a cast is possible. Moved 'as' into RefDeclBase. * Use 'is' to test for as cast on smart pointers. Fix small scope issue. * * Cache stringType and enumTypeType on the Session * Make DeclRefType::Create return a RefPtr * Make casting of result use the *method* .as (cos using free function would mean objects being wrongly destroyed) * Make results from createInstance ref'd to avoid possible leaks. * Fix typo in template parameter for is on RefPtr. 2018-12-06T21:30:34+00:00 Tim Foley tfoleyNV@users.noreply.github.com 2018-12-06T21:30:34+00:00 urn:sha1:b0c2423f00b910f2f4d5010e6a04114112e294fd * Add more design documents This change adds a set of documents about the design/implementation of the Slang compiler intended for helping to onboard new contributors, explain some of the choices that go into the current implementation, and outline the broad strokes of some of our future feature goals. As explained in the `README` for these docs, I don't expect them to be kept in sync with the code in the long run; there is no expectation that people making a PR for code changes also go and fix up these documents. The purpose of these is to add a bit of a "historical record" of design choices and project goals to the project itself, so they can be browsed in a way that is more convenient than the issue tracker or source control history. The "Coding Conventions" document is very much a first attempt, and I'm not 100% wedded to any of the decisions in there. We haven't enforced consistent conventions so far, but the importance of having something in place will only grow with the number of contributors. * Edits based on review * Fix many typos (thanks @jsmall-nvidia) * Change up some language in coding conventions based on discussions since when it was originally written. I'm still not 100% sure about some of the choices in there, but we need to get *something* established.