In https://bugzilla.mozilla.org/show_bug.cgi?id=2058465, the analysis (done before jonco's comment 1) said:
Correctness was verified by source analysis. No build was run: the change is a pure (void) cast on an already-valid bool expression (cannot alter compilation validity), no objdir/mozconfig exists so a build would be a full multi-tens-of-minutes clean build, and a CHECKED_RETURN finding has no runtime testcase to reproduce.
When I run Claude locally to confirm/dispute hackbot's analysis, it made another analysis and at the end said:
Recommended verification path
Given this is P3/CHECKED_RETURN with no runtime testcase, a full build to empirically confirm is expensive for what it buys you. Cheaper and more conclusive:
- Go back to Jon Coppeard on the bug with the concrete trace (RootMarking.cpp:435 → GC.cpp:6054 → TracingAPI.h:383/nsWrapperCache.h:325) and ask him to reconcile it with his "yes" — he's in the best position to instantly say whether he considered the ClearEdgesTracer shutdown path when he answered, since he wrote the null-edge-handling code himself.
- Only if he still disagrees after seeing the trace, escalate to an actual debug build + ./mach jsapi-tests/./mach run (debug) shutdown test to see if MOZ_ALWAYS_TRUE trips — that's the real empirical check, but it's the expensive fallback, not the first move.
This is suboptimal, verification should always happen before reaching out to developers, because saving developers time is more important than spending some time to build and run Firefox.
In https://bugzilla.mozilla.org/show_bug.cgi?id=2058465, the analysis (done before jonco's comment 1) said:
When I run Claude locally to confirm/dispute hackbot's analysis, it made another analysis and at the end said:
This is suboptimal, verification should always happen before reaching out to developers, because saving developers time is more important than spending some time to build and run Firefox.