summaryrefslogtreecommitdiffstats
path: root/tests/preprocessor/include-multiple.slang.expected
diff options
context:
space:
mode:
authorTim Foley <tfoleyNV@users.noreply.github.com>2020-12-07 14:17:17 -0800
committerGitHub <noreply@github.com>2020-12-07 14:17:17 -0800
commit0404fefd7f783d43b5bb636383797adbd593af51 (patch)
tree7ad66422b8858018ec9235a655b7fafa30c83fc9 /tests/preprocessor/include-multiple.slang.expected
parentd7ce74a3f7f941ffba5a9fa73b0d7d559897d6e7 (diff)
Fix mistake where some public API functions weren't extern "C" (#1631)
This was a serious problem that meant that some of our public API functions (exported from the DLL) had mangled C++ symbol names (which are not guaranteed to be portable across different compilers). The fix here is the expedient one: just add `extern "C"` to the relevant functions. The simplicity has a cost, though, in that this change introduces a significant break in binary compatibility. Source code should be compatible before/after this change, but it would be necessary to match an application and Slang shared library so that they agree on the mangled names of these symbols. We will need to treat this as a breaking release when this change goes out. Note that because of the way that C++ mangled names were being used, we *already* have introduced breaking changes to the binary interface in a recent change that made `SlangCompileRequest` into a `typedef` instead of a forward-declared `struct` type. To be clear, the breakage was due to the missing `extern "C"` and *not* the content of that change; the change would have been binary-compatible if the symbol names were correct. Given that the cat is out of the bag to some extent (our next release is going to break compatibility one way or another), it seems best to just get the whole thing sorted at once.
Diffstat (limited to 'tests/preprocessor/include-multiple.slang.expected')
0 files changed, 0 insertions, 0 deletions