Constant byte index xxx is out of bounds of `` errors (Naga)

[hakolao]

EDIT from @ErichDonGubler: WGPU has a limitation with SPIR-V and Naga shader module APIs where a user cannot provide original source code. When an error is encountered in Naga's shader module compilation (i.e., a validation error), WGPU attempts to render the Naga error with an empty string as the source code for these shader modules. Hopefully obviously, this is incompatible with the non-zero span indices that these errors may carry. We expect this to be applicable to the vast majority of errors a user may encounter during shader compilation. 😬

Original OP below.

---

Apologies for a not so helpful bug report, but perhaps you know what was changed in naga in 22.0 (or previous version).

I recreate my pipelines using on_uncaptured_error (hot reload), and quite often now I get following kinds of panics:

[2024-09-17T11:35:14Z ERROR wgpu_core::device::global] Device::create_shader_module error:
    Shader validation error:
      ┌─ Combine shader:1:1
      │
    1 │
      │
      │
      │ naga::Expression [42]
      │ naga::Function [13]


thread 'main' panicked at C:\...\.cargo\registry\src\index.crates.io-6f17d22bba15001f\naga-22.1.0\src\span.rs:73:29:
byte index 4424 is out of bounds of ``

I don't think this should happen, because previously I just got the error nicely printed out and I could keep changing my shaders and running my hot-reloads.

Some errors don't cause this, others do.

[jimblandy]

Thanks for the bug report! Which language are your shaders written in?

In general, we're much more likely to be able to act on an issue when it includes steps to reproduce, not just a general description of what went wrong in your own code. (This is in the issue template, BTW, hint hint.)

So, could your provide an example we can use to reproduce the problem on our own machines?

[hakolao]

Ok, perhaps this willl help:

This is mostly a minimal example: In this branch: https://github.com/hakolao/glass/tree/repro-out-of-bounds-bug

run cargo run --example shader_with_includes

While running, modify triangle_with_include.wgsl from

fn test_function(some_vec: vec2<f32>) -> vec3<f32> {
    return vec3<f32>(some_vec, 1.0);
}

to

fn test_function(some_vec: vec2<f32>) -> vec3<f32> {
    return vec2<f32>(some_vec, 1.0);
}

(Obvious mistake, but should not crash).

Results with error:

byte index 379 is out of bounds of ``

[mobile-bungalow]

https://github.com/mobile-bungalow/naga_bug_repro

another repro.

the cause is this line. Naga assumes the source exists when formatting the panic but it is set to an empty string here. Perhaps naga modules should optionally contain a copy of the source for debug purposes?

[ErichDonGubler]

To summarize the above: WGPU has a limitation with SPIR-V and Naga shader module APIs where a user cannot provide original source code. When an error is encountered in shader module compilation (i.e., a validation error), WGPU attempts to render the error with an empty string as the source code for these shader modules. Hopefully obviously, this is incompatible with the non-zero span indices that these errors may carry. I would expect this to be applicable to the vast majority of errors. I've amended the OP so that this is clear.

I believe that, at least on Firefox's end, this isn't relevant (we only ever compile WGSL shaders from provided source code), so that limits how high that Firefox contributors can prioritize this for now.

I think that there's two possible action items here WRT resolution:

1. Change wgpu::ShaderSource::{Naga,Spirv}/wgpu_core::pipeline::ShaderSource::{Naga,Spirv} so that source code is provided with them. This way, WGPU can use the source code to render Naga errors without panicking.
2. Document that emit* methods with source code as parameters on the various error types in Naga should be passed the same source code with which the Naga module was created, or the method may panick and/or write incorrect information.

☝🏻CC @gfx-rs/naga.

Firefox note: Moved this out of our needs investigation priority.