diff options
| author | Tim Foley <tfoley@nvidia.com> | 2017-08-15 12:46:51 -0700 |
|---|---|---|
| committer | Tim Foley <tfoley@nvidia.com> | 2017-08-15 12:46:51 -0700 |
| commit | d094bfc5aa0deebfb16f7678603d45ac2a7aa215 (patch) | |
| tree | 8e638979cddc7d78ebbfa9390ffdd2961ec84944 /source | |
| parent | e6abc6821a1bf13a9826e7db74362ce34ccaca2a (diff) | |
Add user-defined builtins to the "core" module
The Slang API allows an expert user to feed in source code that the compiler then treats as if it came from the Slang "standard library."
They can use this to introduce new builtin types, functions, etc. - so long as they are careful, and are willing to deal with the lack of any compatibility guarantees across versions.
At some point I split the Slang standard library into distinct modules, so that GLSL and HLSL builtins wouldn't pollute each other's namespace.
In that change, I had to decide what module any new user-defined builtins should get added to, and I apparently decided they should go into the module for the Slang language, which would only affect `.slang` files.
This doesn't work at all if the user wants to declare new HLSL builtins.
I've gone ahead and made user extensions add to the "core" module (which is used by all of HLSL, GLSL, and Slang), but a better long-term fix would be to let the user pick the module/language the new builtins should apply to.
Diffstat (limited to 'source')
| -rw-r--r-- | source/slang/slang.cpp | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/source/slang/slang.cpp b/source/slang/slang.cpp index f6e9bd70b..293b6bf9e 100644 --- a/source/slang/slang.cpp +++ b/source/slang/slang.cpp @@ -648,7 +648,7 @@ SLANG_API void spAddBuiltins( s->addBuiltinSource( // TODO(tfoley): Add ability to directly new builtins to the approriate scope - s->slangLanguageScope, + s->coreLanguageScope, sourcePath, sourceString); |
