compiler-builtins: pass -fdebug-compilation-dir=. to fix S_OBJNAME reproducibility on Windows by paradoxicalguy · Pull Request #157914 · rust-lang/rust

paradoxicalguy · 2026-06-15T11:42:07Z

compiler_builtins.rlib differs between builds because clang-cl embeds the absolute object output path into the S_OBJNAME codeview record.
the path comes from cc-rs passing an absolute /Fo argument (derived from cargo's OUT_DIR) to addDebugObjectName(), which llvm then writes verbatim into .debug$S.
minimal repro:

clang-cl /c /Z7 t.c /Fo:a\t.obj  →  ObjectName: C:\...\a\t.obj
clang-cl /c /Z7 t.c /Fo:b\t.obj  →  ObjectName: C:\...\b\t.obj

-fdebug-compilation-dir=. makes S_OBJNAME emit a relative path instead.
needs CI verification on a windows dist job since local builds use cl.exe rather than the bundled clang-cl. this pr is only for testing

rustbot · 2026-06-15T11:42:10Z

compiler-builtins is developed in its own repository. If possible, consider making this change to rust-lang/compiler-builtins instead.

cc @tgross35

rustbot · 2026-06-15T11:42:13Z

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Fallback group: @Mark-Simulacrum, @jieyouxu
@Mark-Simulacrum, @jieyouxu expanded to Mark-Simulacrum, jieyouxu
Random selection from Mark-Simulacrum, jieyouxu

paradoxicalguy · 2026-06-15T14:10:41Z

cc @bjorn3 @Urgau

bjorn3 · 2026-06-16T11:57:01Z

@bors try job=dist-x86_64-msvc

…oducibility, r=<try> compiler-builtins: pass -fdebug-compilation-dir=. to fix S_OBJNAME reproducibility on Windows try-job: dist-x86_64-msvc

rust-bors · 2026-06-16T14:57:15Z

☀️ Try build successful (CI)
Build commit: 5383ff6 (5383ff6bb690cf094a2399cf3e129092120625b2, parent: 9d862dd2c17b2dc90e9f623bb9279a8c4090b311)

paradoxicalguy · 2026-06-16T18:49:25Z

where can i download the x86_64-msvc artifact from this try build to extract ucmpti2.o and verify S_OBJNAME?

bjorn3 · 2026-06-16T20:17:56Z

You can use rustup-toolchain-install-master I think you can do something like rustup-toolchain-install-master 5383ff6bb690cf094a2399cf3e129092120625b2 --host x86_64-pc-windows-msvc and then check ~/.rustup/toolchain/5383ff6bb690cf094a2399cf3e129092120625b2/lib/rustlib/x86_64-pc-windows-msvc/lib/libcompiler_builtins-*.rlib Afterwards you can remove it again with rustup toolchain remove 5383ff6bb690cf094a2399cf3e129092120625b2 I think. Make sure that rustup-toolchain-install-master downloads the correct commit, by default or if you pass the commit hash at the wrong location it downloads for the top of the main branch.

ChrisDenton · 2026-06-16T21:24:19Z

needs CI verification on a windows dist job since local builds use cl.exe rather than the bundled clang-cl. this pr is only for testing

IIRC you should be able to use something like --set target.x86_64-pc-windows-msvc.cc = "clang-cl.exe" to override the linker (or put the setting in your bootstrap.toml)

paradoxicalguy · 2026-06-17T09:44:27Z

thanks to both of you, i checked in downloaded artifact, sadly patch didn't work,
but now i can test this locally with --set target.x86_64-pc-windows-msvc.cc = "clang-cl.exe" so that's good

tgross35 · 2026-06-17T21:54:28Z

Is this something that you can figure out by inspecting the object file? If so, you could create a PR to the compiler-builtins repo adding a failing test to https://github.com/rust-lang/compiler-builtins/blob/fb48f81544cf29e6ff7fb4468c8b2e1dacd42b79/crates/symbol-check/src/main.rs then messing around to see what flags get it to pass. Might be easier than repeating the try build process here.

Why does this only apply to Windows, though, and only compiler-builtins? I'd expect other platforms to get the same paths in their debug info.

paradoxicalguy · 2026-06-18T05:59:18Z

(a) yes, i found the current problem by inspecting an object file, extracting ucmpti2.o and running llvm-readobj --codeview on it, shows S_OBJNAME containing absolute path. (it came empty on my local patch but comes absolute path on ci so i am missing something, maybe different bootstrap or some flags.)
(b) on elf, it only saves the filename and not the whole path, not resulting in non determinism.
while codeview's S_OBJNAME record was designed to store the full absolute object path, since windows debugging tools (visual studio, windbg) use it to locate the original .obj on disk.

@tgross35

paradoxicalguy · 2026-06-18T06:52:45Z

it works w build.flag("/clang:-object-file-name="); in compiler-builtins repo.

paradoxicalguy · 2026-06-19T08:00:52Z

repro_report.html

the objname issue is resolved when checked manually but compiler-builtins still comes as non-deterministic in the repro check run i did. archive still contains absolute build paths (e.g. the build-b/extra1/... path), so im investigating whether those are coming from archive member names / the archive string table.

paradoxicalguy · 2026-06-28T10:55:32Z

update on the .rlib

i patched compiler-builtins/build.rs to re-archive libcompiler-rt.a using bare filenames, verified the resulting libcompiler-rt.a contains only bare member names (e.g. 7a40cf3a9ab24310-cmpti2.o).
extracting the final libcompiler_builtins.rlib also produces bare filenames.

however, llvm-ar t libcompiler_builtins.rlib still shows absolute build paths as the archive member names, and these differ between build A/B.
it seems like the absolute paths are being introduced during the final .rlib packaging step rather than by compiler-builtins itself.

…ember names)

rustbot · 2026-07-26T21:46:49Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

paradoxicalguy · 2026-07-26T23:00:26Z

both the intermediate compiler-rt archive and the final rlib now show only bare filenames, no absolute paths :D

full terminal output

PS C:\rust3> cd C:\rust3\build\x86_64-pc-windows-msvc\stage1-std\x86_64-pc-windows-msvc\dist\build\compiler_builtins-a81d241a7aad8bc9\out

PS C:\rust3\build\x86_64-pc-windows-msvc\stage1-std\x86_64-pc-windows-msvc\dist\build\compiler_builtins-a81d241a7aad8bc9\out> llvm-ar t libcompiler-rt.a | Select-Object -First 30
7a40cf3a9ab24310-ucmpti2.o
7a40cf3a9ab24310-ucmpdi2.o
7a40cf3a9ab24310-subvti3.o
7a40cf3a9ab24310-subvsi3.o
7a40cf3a9ab24310-subvdi3.o
7a40cf3a9ab24310-popcountti2.o
7a40cf3a9ab24310-popcountsi2.o
7a40cf3a9ab24310-popcountdi2.o
7a40cf3a9ab24310-parityti2.o
7a40cf3a9ab24310-paritysi2.o
7a40cf3a9ab24310-negvti2.o
7a40cf3a9ab24310-negvsi2.o
7a40cf3a9ab24310-negvdi2.o
7a40cf3a9ab24310-negti2.o
7a40cf3a9ab24310-negsf2.o
7a40cf3a9ab24310-negdi2.o
7a40cf3a9ab24310-negdf2.o
7a40cf3a9ab24310-mulvti3.o
7a40cf3a9ab24310-mulvsi3.o
7a40cf3a9ab24310-mulvdi3.o
7a40cf3a9ab24310-mulsc3.o
7a40cf3a9ab24310-muldc3.o
7a40cf3a9ab24310-int_util.o
7a40cf3a9ab24310-ffsti2.o
7a40cf3a9ab24310-divsc3.o
7a40cf3a9ab24310-divdc3.o
7a40cf3a9ab24310-cmpti2.o
7a40cf3a9ab24310-cmpdi2.o
7a40cf3a9ab24310-addvti3.o

PS C:\rust3\build\x86_64-pc-windows-msvc\stage1-std\x86_64-pc-windows-msvc\dist\build\compiler_builtins-a81d241a7aad8bc9\out> cd C:\rust3\build\x86_64-pc-windows-msvc\stage2\lib\rustlib\x86_64-pc-windows-msvc\lib

PS C:\rust3\build\x86_64-pc-windows-msvc\stage2\lib\rustlib\x86_64-pc-windows-msvc\lib> llvm-ar t libcompiler_builtins-9da03b385e27b6a1.rlib | Select-Object -First 50
lib.rmeta
lib.rmeta-link
compiler_builtins-9da03b385e27b6a1.compiler_builtins.66a41a7ced20cbfb-cgu.000.rcgu.o
compiler_builtins-9da03b385e27b6a1.compiler_builtins.66a41a7ced20cbfb-cgu.001.rcgu.o
compiler_builtins-9da03b385e27b6a1.compiler_builtins.66a41a7ced20cbfb-cgu.002.rcgu.o
compiler_builtins-9da03b385e27b6a1.compiler_builtins.66a41a7ced20cbfb-cgu.003.rcgu.o
compiler_builtins-9da03b385e27b6a1.compiler_builtins.66a41a7ced20cbfb-cgu.004.rcgu.o
compiler_builtins-9da03b385e27b6a1.compiler_builtins.66a41a7ced20cbfb-cgu.005.rcgu.o
compiler_builtins-9da03b385e27b6a1.compiler_builtins.66a41a7ced20cbfb-cgu.006.rcgu.o
compiler_builtins-9da03b385e27b6a1.compiler_builtins.66a41a7ced20cbfb-cgu.007.rcgu.o
compiler_builtins-9da03b385e27b6a1.compiler_builtins.66a41a7ced20cbfb-cgu.008.rcgu.o
compiler_builtins-9da03b385e27b6a1.compiler_builtins.66a41a7ced20cbfb-cgu.009.rcgu.o
... (240 rcgu.o entries total, truncated for brevity)

PS C:\rust3\build\x86_64-pc-windows-msvc\stage2\lib\rustlib\x86_64-pc-windows-msvc\lib> llvm-ar t "C:\rust3\build\x86_64-pc-windows-msvc\stage1-std\x86_64-pc-windows-msvc\dist\build\compiler_builtins-a81d241a7aad8bc9\out\libcompiler-rt.a"
7a40cf3a9ab24310-ucmpti2.o
7a40cf3a9ab24310-ucmpdi2.o
7a40cf3a9ab24310-subvti3.o
7a40cf3a9ab24310-subvsi3.o
7a40cf3a9ab24310-subvdi3.o
7a40cf3a9ab24310-popcountti2.o
7a40cf3a9ab24310-popcountsi2.o
7a40cf3a9ab24310-popcountdi2.o
7a40cf3a9ab24310-parityti2.o
7a40cf3a9ab24310-paritysi2.o
7a40cf3a9ab24310-negvti2.o
7a40cf3a9ab24310-negvsi2.o
7a40cf3a9ab24310-negvdi2.o
7a40cf3a9ab24310-negti2.o
7a40cf3a9ab24310-negsf2.o
7a40cf3a9ab24310-negdi2.o
7a40cf3a9ab24310-negdf2.o
7a40cf3a9ab24310-mulvti3.o
7a40cf3a9ab24310-mulvsi3.o
7a40cf3a9ab24310-mulvdi3.o
7a40cf3a9ab24310-mulsc3.o
7a40cf3a9ab24310-muldc3.o
7a40cf3a9ab24310-int_util.o
7a40cf3a9ab24310-ffsti2.o
7a40cf3a9ab24310-divsc3.o
7a40cf3a9ab24310-cmpti2.o
7a40cf3a9ab24310-cmpdi2.o
7a40cf3a9ab24310-addvti3.o
7a40cf3a9ab24310-addvsi3.o
7a40cf3a9ab24310-addvdi3.o
7a40cf3a9ab24310-absvti2.o
7a40cf3a9ab24310-absvsi2.o
7a40cf3a9ab24310-absvdi2.o

PS C:\rust3\build\x86_64-pc-windows-msvc\stage2\lib\rustlib\x86_64-pc-windows-msvc\lib> llvm-ar t "C:\rust3\build\x86_64-pc-windows-msvc\stage1-std\x86_64-pc-windows-msvc\dist\build\compiler_builtins-a81d241a7aad8bc9\out\compiler-rt.lib"
7a40cf3a9ab24310-ucmpti2.o
7a40cf3a9ab24310-ucmpdi2.o
7a40cf3a9ab24310-subvti3.o
7a40cf3a9ab24310-subvsi3.o
7a40cf3a9ab24310-subvdi3.o
7a40cf3a9ab24310-popcountti2.o
7a40cf3a9ab24310-popcountsi2.o
7a40cf3a9ab24310-parityti2.o
7a40cf3a9ab24310-negvti2.o
7a40cf3a9ab24310-negvsi2.o
7a40cf3a9ab24310-negvdi2.o
7a40cf3a9ab24310-negti2.o
7a40cf3a9ab24310-negsf2.o
7a40cf3a9ab24310-negdi2.o
7a40cf3a9ab24310-negdf2.o
7a40cf3a9ab24310-mulvti3.o
7a40cf3a9ab24310-mulvsi3.o
7a40cf3a9ab24310-mulvdi3.o
7a40cf3a9ab24310-mulsc3.o
7a40cf3a9ab24310-muldc3.o
7a40cf3a9ab24310-int_util.o
7a40cf3a9ab24310-ffsti2.o
7a40cf3a9ab24310-divsc3.o
7a40cf3a9ab24310-divdc3.o
7a40cf3a9ab24310-cmpti2.o
7a40cf3a9ab24310-cmpdi2.o
7a40cf3a9ab24310-addvti3.o
7a40cf3a9ab24310-addvsi3.o
7a40cf3a9ab24310-addvdi3.o
7a40cf3a9ab24310-absvti2.o
7a40cf3a9ab24310-absvsi2.o
7a40cf3a9ab24310-absvdi2.o

</details> ```

paradoxicalguy · 2026-07-29T11:08:46Z

@Fulgen301

tgross35 · 2026-07-29T16:12:02Z

+    /// Resolve the archiver tool cc-rs/bootstrap configured for this target.
+    /// cc-rs checks both the dash and underscore forms of `AR_<target>`,
+    /// falling back to a plain `AR`, and finally the bare tool name on PATH.
+    fn find_archiver_tool(name: &str) -> PathBuf {
+        let target = env::var("TARGET").unwrap_or_default();
+        let dash_var = format!("AR_{target}");
+        let underscore_var = format!("AR_{}", target.replace('-', "_"));
+
+        let resolved = env::var_os(&dash_var)
+            .or_else(|| env::var_os(&underscore_var))
+            .or_else(|| env::var_os("AR"))
+            .map(PathBuf::from);
+
+        match resolved {
+            // Swap the resolved archiver's directory in, but use `name` itself
+            // (llvm-ar vs llvm-lib) rather than assuming the configured AR is
+            // the right tool for both extraction and re-archiving.
+            Some(path) => match path.parent() {
+                Some(dir) if !dir.as_os_str().is_empty() => dir.join(format!("{name}.exe")),
+                _ => PathBuf::from(name),
+            },
+            None => PathBuf::from(name),
+        }
+    }
+
+    /// The compiler-rt archive contains absolute object paths because the
+    /// archiver records whatever input paths it's given as member names.
+    /// Since compiler-builtins passes object files from OUT_DIR (absolute,
+    /// build-path-dependent), those become the archive's member names,
+    /// making the archive non-reproducible across build paths.
+    ///
+    /// We fix this by extracting all members and re-archiving them using only
+    /// their bare filenames, so the archive's metadata no longer depends on
+    /// where the build happened.
+    fn rearchive_with_bare_names() {
+        let out_dir = PathBuf::from(env::var("OUT_DIR").unwrap());
+
+        for name in ["libcompiler-rt.a", "compiler-rt.lib"] {
+            let archive = out_dir.join(name);
+            if archive.exists() {
+                rebuild_archive_with_bare_names(&archive);
+            }
+        }
+    }
+
+    fn rebuild_archive_with_bare_names(archive: &Path) {
+        let tmp_dir = archive.parent().unwrap().join("relib_tmp");
+
+        if tmp_dir.exists() {
+            fs::remove_dir_all(&tmp_dir).expect("failed to remove temporary rearchive directory");
+        }
+        fs::create_dir_all(&tmp_dir).expect("failed to create temporary rearchive directory");
+
+        let ar = find_archiver_tool("llvm-ar");
+        let lib = find_archiver_tool("llvm-lib");
+
+        // Extract members into a temporary directory, then re-archive them using
+        // only their filenames. This avoids carrying over path-dependent member names
+        // from the original archive.
+        let status = Command::new(&ar)
+            .arg("x")
+            .arg(archive)
+            .current_dir(&tmp_dir)
+            .status()
+            .unwrap_or_else(|e| panic!("failed to execute {}: {e}", ar.display()));
+        assert!(status.success(), "{} failed to extract archive", ar.display());
+
+        let mut objs: Vec<_> = fs::read_dir(&tmp_dir)
+            .expect("failed to read extraction directory")
+            .filter_map(Result::ok)
+            .map(|e| e.file_name())
+            .filter(|name| {
+                Path::new(name)
+                    .extension()
+                    .map_or(false, |ext| ext == "o" || ext == "obj")
+            })
+            .collect();
+        assert!(!objs.is_empty(), "archive extraction produced no object files");
+
+        // read_dir order isn't guaranteed stable across machines/runs; sort so
+        // the re-archived member order is deterministic.
+        objs.sort();
+
+        // Build the replacement archive at a temp path first, so a failed
+        // llvm-lib invocation doesn't leave us without any archive at all.
+        let tmp_archive = archive.with_file_name(format!(
+            "{}.tmp",
+            archive.file_name().unwrap().to_string_lossy()
+        ));
+        if tmp_archive.exists() {
+            fs::remove_file(&tmp_archive).expect("failed to remove stale temp archive");
+        }
+
+        // Re-archive from inside tmp_dir, passing only bare filenames, so
+        // llvm-lib stores bare names as the member names.
+        let status = Command::new(&lib)
+            .arg(format!("-out:{}", tmp_archive.display()))
+            .arg("-nologo")
+            .args(&objs)
+            .current_dir(&tmp_dir)
+            .status()
+            .unwrap_or_else(|e| panic!("failed to execute {}: {e}", lib.display()));
+        assert!(status.success(), "{} failed to rebuild archive", lib.display());
+
+        fs::rename(&tmp_archive, archive).expect("failed to replace archive with rebuilt version");
+
+        fs::remove_dir_all(&tmp_dir).expect("failed to remove temporary rearchive directory");
+    }


This is quite a lot of logic to have in a build script. Could we put this functionality into rustc somehow and access it with a flag?

View changes since the review

i wasn't sure where the right abstraction would be, since this archive is produced by the external C toolchain rather than by rustc's own archive generation. were you picturing a rustc/bootstrap mechanism that build scripts could opt into, or something else? i'd definitely prefer moving the logic out of the build script if there's a cleaner/preferable place for it.

Ah sorry right, I was thinking this was for the Rust bits.

Is the summary basically that we need an archive where lib.exe is invoked with relative paths rather than absolute? This feels like an option that cc might be able to handle, especially if it's going to be useful elsewhere. Maybe it should even be the default?

oh shoot, this didnt appear when i loaded the website, but answers my zulip q, and that sounds like a better/cleaner approach, tho i dont know well enough about cc-rs atp, i'll get on it and happy to test it against this fix,
not sure about the api design rn tho

Got a link to the Zulip thread? I haven't seen it.

Actually, after thinking about this some more, could we use ar_archive_writer in compiler_builtins? If the goal is reproducibility then that's our most stable option since it's fully under our control.

that seems interesting, i haven't tried or even thought of that
im happy to experiment and try that fix!

Good thought, that seems reasonable to me.

@paradoxicalguy I think you're probably already aware but any kind of build system changes for c-b should go via the c-b repo, quite a bit more gets tested there. Or at least tested in a draft PR there if you want to write a run-make test here.

(There's also symcheck in that repo that could probably be extended for testing)

On second thought, maybe that's also something that could be done in cc if a Cargo feature is enabled? Assuming whatever build script pattern we come up with would probably have to be duplicated anywhere else that cares about reproduceability, that would make it easier to share.

i'll experiment with ar_archive_writer in compiler-builtins first and see how well it fits. if it ends up being a generally useful approach rather than something compiler-builtins-specific, we can revisit whether it makes sense to expose it through cc-rs
and yes, i'll open in c-b if we go ahead that way :D

jieyouxu · 2026-08-04T09:09:32Z

Maybe r? tgross35

rustbot · 2026-08-04T09:09:37Z

tgross35 is currently at their maximum review capacity.
They may take a while to respond.

tgross35 · 2026-08-04T09:26:59Z

@rustbot author for now

rustbot · 2026-08-04T09:27:03Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

rustbot added A-compiler-builtins Area: compiler-builtins (https://github.com/rust-lang/compiler-builtins) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 15, 2026

rustbot assigned jieyouxu Jun 15, 2026

This comment has been minimized.

Sign in to view

rustbot added has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 15, 2026

bjorn3 reviewed Jun 15, 2026

View reviewed changes

Comment thread library/compiler-builtins/compiler-builtins/build.rs Outdated

This comment has been minimized.

Sign in to view

jieyouxu removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 23, 2026

paradoxicalguy mentioned this pull request Jul 18, 2026

tests: extend remap-path-prefix-std to all stdlib rlibs #156570

Merged

compiler-builtins: fix Windows reproducibility (S_OBJNAME + archive m…

5b79843

…ember names)

paradoxicalguy force-pushed the compiler-builtins-objname-reproducibility branch from 5ba7fa8 to 5b79843 Compare July 26, 2026 21:46

rustbot removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. has-merge-commits PR has merge commits, merge with caution. labels Jul 26, 2026

tgross35 reviewed Jul 29, 2026

View reviewed changes

tgross35 mentioned this pull request Jul 30, 2026

Make it possible to recreate the results of compile via compile_intermediates rust-lang/cc-rs#1818

Open

rustbot assigned tgross35 Aug 4, 2026

rustbot unassigned jieyouxu Aug 4, 2026

rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 4, 2026

Uh oh!

Uh oh!

Conversation

paradoxicalguy commented Jun 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 15, 2026

Uh oh!

rustbot commented Jun 15, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

paradoxicalguy commented Jun 15, 2026

Uh oh!

Uh oh!

bjorn3 commented Jun 16, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jun 16, 2026

Uh oh!

paradoxicalguy commented Jun 16, 2026

Uh oh!

bjorn3 commented Jun 16, 2026

Uh oh!

ChrisDenton commented Jun 16, 2026

Uh oh!

paradoxicalguy commented Jun 17, 2026

Uh oh!

tgross35 commented Jun 17, 2026

Uh oh!

paradoxicalguy commented Jun 18, 2026

Uh oh!

paradoxicalguy commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

paradoxicalguy commented Jun 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

paradoxicalguy commented Jun 28, 2026

Uh oh!

rustbot commented Jul 26, 2026

Uh oh!

paradoxicalguy commented Jul 26, 2026

Uh oh!

paradoxicalguy commented Jul 29, 2026

Uh oh!

tgross35 Jul 29, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paradoxicalguy Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

tgross35 Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

paradoxicalguy Jul 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

ChrisDenton Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

paradoxicalguy Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

tgross35 Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

tgross35 Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

paradoxicalguy Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paradoxicalguy commented Jun 15, 2026 •

edited by rustbot

Loading

paradoxicalguy commented Jun 18, 2026 •

edited

Loading

paradoxicalguy commented Jun 19, 2026 •

edited

Loading

tgross35 Jul 29, 2026 •

edited by rustbot

Loading

paradoxicalguy Jul 30, 2026 •

edited

Loading

paradoxicalguy Jul 31, 2026 •

edited

Loading