Fix GPUError message persistence in device.popErrorScope()

[Copilot]

The device.popErrorScope() method was returning empty or garbage error messages instead of the actual WebGPU error text. This was caused by the GPUError class storing the error message as a char const * pointer, which became invalid after the WebGPU callback returned.

Problem

const redFragWGSL = `@fragment
fn main() -> @location(0) vec4f {
  return vec4(1.0, 0.0, 0.0, 1.0;  // Missing closing parenthesis
}`;

device.pushErrorScope('validation');
const redFragModule = device.createShaderModule({
  code: redFragWGSL,
});

const error = await device.popErrorScope();
if (error) {
  console.log('Error message: ', error.message);
  // Before: Empty string or garbage
  // Expected: "Error while parsing WGSL: :3:33 error: expected ',' for function call..."
}

Root Cause

The GPUError class was storing the error message as a char const * pointer:

class GPUError {
  wgpu::ErrorType type;
  char const *message;  // Problem: pointer becomes invalid after callback
};

When the WebGPU callback completed, the underlying string memory could be deallocated, leaving the pointer pointing to invalid memory.

Solution

Changed GPUError to store the message as a std::string to ensure proper string persistence:

class GPUError {
public:
  GPUError(wgpu::ErrorType aType, char const *aMessage)
      : type(aType), message(aMessage ? aMessage : "") {}  // Copy string safely

  wgpu::ErrorType type;
  std::string message;  // Stores actual string data
};

Changes Made

• GPUError.h: Changed message field from char const * to std::string
• Constructor: Added null-check and string copying
• JSIConverter: Updated to use c_str() for proper string conversion
• Tests: Added comprehensive test coverage for error scope functionality

Testing

Added ErrorScope.spec.ts with tests that verify:

• Error messages are properly captured and returned with actual content
• No errors are returned when no validation issues occur
• Error messages contain meaningful WGSL parsing information

The fix is fully backward compatible with no API changes required.

Fixes #212.

Warning

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

• googlechromelabs.github.io
  • Triggering command: /usr/local/bin/node install.mjs (dns block)
• https://storage.googleapis.com/chrome-for-testing-public/127.0.6533.88/linux64/chrome-linux64.zip
  • Triggering command: /usr/local/bin/node install.mjs (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to my firewall allow list

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.