All posts

On one stripped Rust binary, a Ghidra 12.2 headless run (import, default analysis, one decompilation) took 57 to 59 s and found 1,123 of 2,096 function starts. Single xref commands took 2.5 to 6.4 ms and matched all 2,096. Plus two places where Ghidra is right and xref is not.

A remote build is only as good as the copy it builds. Three bug reports filed within one minute showed three ways the gateway's copy had drifted from the checkout: files cut by extension, directories that never went away, and a Swift package that never reached the Mac.

Turning an associated function into a method is the mirror of making a method static, and the easier half. Writing it turned up something else: every write tool in the project reported an empty diff once it had applied its edit, because the old text was read after it was overwritten.

A type migration that writes .into() at every broken site sounds like the dangerous version. It holds up when the analyzer decides which conversions stay: only the ones that type-check and break nothing else are kept; the rest are taken back and left for a person. Type-correct, not judged right.

A declaration edit can leave call text unchanged while breaking type inference. The original generify report illustrates why callers still need checking, and why failed caller discovery must stop the plan.

Inverting a boolean predicate requires changing both its body and its uses. Three direct-call shapes explain the negations and parentheses; a September prod-code implementation also shows the limits of reference discovery and textual rewriting.

Removing an unused receiver can still remove an evaluation at the call site. A September prod-code implementation blocked selected receiver shapes; its textual rule shows why type checks alone cannot establish that a rewrite preserves behaviour.

A September rust-analyzer probe wrapped a function’s return type without updating its callers. The first prod-code implementation added propagation candidates and a report of unresolved calls. Its limits show why the caller side needs a separate check.

September's prod-code fixes exposed a per-file exception that skipped its own case, a refusal that said too much, and an estimated cost replaced by a reported measurement. What those records teach about checking a fix.

Checking a proposed edit to a large file took half a minute, and running the check on sixteen threads changed almost nothing. The cause was a single function. Splitting it with the tool itself took the check to four seconds; the work turned up six bugs in the tool.

A Swift subproject can sit inside a Rust checkout, and a validation request can disturb the engine answering navigation queries. How prod-code v0.3.29 chooses a compatible node and separates proposed edits from ordinary analysis.

Turning a value computed inside a method into a field is three small edits. The hard part is the third: finding every place the struct is built, among everything the analyzer calls a reference to it. Imports, return types and `Self` all qualify, and a pattern that lists every field breaks.

A dry run is supposed to be the cheap step. Here it cost the next query, whoever asked it, twenty seconds. Moving validation onto a second analyzer fixed that, but the first measurement of the fix was taken on the wrong machine, and the second showed the cost had only moved.

A new refactoring made a field private and rewrote every access to it, and its diff was right. Its verdict was 124 errors. The unchanged file reported the same 124, and every write tool had been counting them; our reading is that none of them was the edit's.

Four bugs fixed in one afternoon, in the tools that write your code, and every one of them was a place where a tool took something on trust: a position, a write, a verdict, a line number. What each one did, how it was found, and what it checks now.