-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Description
Split from #24588.
When using zig build --fuzz, the WebAssembly code uses some incorrect logic to decide which module each file in the compilation belongs to. This results in the source code view in the web UI being pretty broken: it can only render the code at all if you're looking at the root source file of the main module, and link-ified references are completely broken. Here are the relevant pieces of logic:
zig/lib/std/Build/WebServer.zig
Lines 515 to 524 in dcc3e6e
| // TODO: this logic is completely bogus -- obviously so, because `path.root_dir.path` can | |
| // be cwd-relative. This is also related to why linkification doesn't work in the fuzzer UI: | |
| // it turns out the WASM treats the first path component as the module name, typically | |
| // resulting in modules named "" and "src". The compiler needs to tell the build system | |
| // about the module graph so that the build system can correctly encode this information in | |
| // the tar file. | |
| archiver.prefix = path.root_dir.path orelse cwd: { | |
| if (cached_cwd_path == null) cached_cwd_path = try std.process.getCwdAlloc(gpa); | |
| break :cwd cached_cwd_path.?; | |
| }; |
Lines 230 to 232 in dcc3e6e
| const file_name = try gpa.dupe(u8, tar_file.name); | |
| if (std.mem.indexOfScalar(u8, file_name, '/')) |pkg_name_end| { | |
| const pkg_name = file_name[0..pkg_name_end]; |
Fixing this will require the compiler to communicate the resolved module graph back to the build system over std.zig.Server, and the build system to in turn communicate that information to the build system web interface. I would suggest that the best strategy here would be to structure the generated sources.tar archive such that the root contains one directory per module, where that directory corresponds to the module root; and perhaps an extra file in the archive root per module which defines the module's imports (i.e. the --dep flags passed to zig).