Compilation api for SPIR-V no longer works with recent Slang releases, generic error "assert failure: slang-session.cpp(56): blob"

[SaschaWillems]

Issue Description

I've been using the Slang compilation API in several Vulkan projects. Among those is a Vulkan tutorial at https://www.howtovulkan.com. Users have informed me, that Slang shader compilation at runtime using the compilation api is failing with recent Slang versions (e.g. the one included in the recent Vulkan SDK).

I can reproduce this, but sadly the error I get via diagnostics is not helpful, it just states:

assert failure: slang-session.cpp(56): blob

Reproducer Code

slang::IBlob* diagnostics = nullptr;
Slang::ComPtr<slang::IModule> slangModule{ session->loadModuleFromSource(createInfo.name.c_str(), createInfo.shaders.filename.c_str(), nullptr, &diagnostics) };
if (diagnostics) {				
	std::cerr << static_cast<const char*>(diagnostics->getBufferPointer()) << std::endl;
}

Expected Behavior

loadModuleFromSource successfully loads the shader and creates a shader module or at least gives me a human readable and reasonable error message in the diagnostics blob.

Actual Behavior

The shader module isn't created, the error message in the diagnostics blob isn't helpful.

Environment

• Slang Version (release version number or commit hash): 2026.16.1
• OS: Windows 11
• GPU/Driver version, if the bug is a runtime result error: Does not apply (not a GPU driver issue)
• Any related environment variables.

[nv-slang-bot]

Triage — confirmed regression (not a bug in your code)

• Status: Triaged — reproduced by code inspection on top-of-tree. Classified Bug / regression / P1 / high; regression label + Type=Bug set. (Not run at runtime here — this is a C++ API path — but the failure is deterministic; see below.)
• Link: Root cause is at source/slang/slang-session.cpp:56 (SLANG_RELEASE_ASSERT(blob) in computeSourceBlobDigest), reached unconditionally from loadModuleFromBlob at :249. Introduced by Fail fast when loadModuleFromSource is called with a colliding name #10996 (commit 3649449, 2026-07-03, "Fail fast when loadModuleFromSource is called with a colliding name", fixing loadModuleFromSource can crash if used incorrectly #10957).
• Verdict: Your usage is correct. loadModuleFromSource(moduleName, path, /*source*/ nullptr, &diag) — passing a null source blob with a valid path — is a supported way to load a module from a file on disk: the internal loader (loadSourceModuleImpl, :1384-1403) explicitly falls back to reading the source from path when the blob is null. Fail fast when loadModuleFromSource is called with a colliding name #10996 added an unconditional SHA-1 digest of the raw source blob (for cache-collision detection) before that fallback runs, so a null source now trips a release assert instead of loading your file. The assert text is what leaks into the diagnostics blob.
• Next-action: Handed to our compiler team to fix. Planned direction: compute the module's content digest from the materialized source (the file contents when source is null, exactly as the by-path loader already does at :1735) rather than from the raw argument — restoring load-from-path while keeping Fail fast when loadModuleFromSource is called with a colliding name #10996's collision protection. A CPU-only regression test (null source + valid path) will be added.
• Blocker: None. Immediate workaround if you're blocked: read the file yourself and pass its bytes as the source blob (e.g. session->createBlob(...) / your own ISlangBlob over the file contents), or use session->loadModule("MyModule", &diag) to load by module name via the search paths. Either avoids the null-source path.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}

[jkwak-work]

@SaschaWillems
Sorry about the trouble.
The fix will be merged soon and the next Slang release package will contain the fix.