[ Removed by moderator ]

•

u/rust-ModTeam 7h ago

Code Dumps violate Rule 6: Low Effort.

1

u/teerre 7h ago

This will likely be deleted under the "code dump" rule, but while it lasts: I'm not sure I understand. Is a "diagnostic" an error? Like I use this in my app and I get these "durable" error chains, is that it?

0

u/cybercore_sh 7h ago

Fair confusion, and the name genuinely doesn't help here.

A diagnostic is not an error. It's a superset — an error is one case of it.

- Error = a value in your control flow. Result<T, E>, it propagates up, gets logged, disappears.

- Diagnostic = the structured record you produce when you decide to surface something. It carries a severity (error / warning / note / help), a stable code, primary + secondary labels pointing at spans, notes, help text, and suggestions.

The tell for which one you're looking at: if everything you've emitted is an error, diagprint will look exactly like a durable error-chain library. That's the trap. Most diagnostics shouldn't be errors. A lint firing 400 warnings in CI is 400 diagnostics with severity warning and not one Err anywhere. And those warnings are what diagprint why and baseline deltas are actually for — "new since main" doesn't mean much if the only thing you ever record is a hard failure.

On the chain specifically: yes, cause chains are in there, but not as flattened strings. Each link can carry its own labels and code, so the output points at the line that actually failed instead of just saying caused by: inner error. Same info, but it survives being rendered to a terminal, serialized to SARIF, and queried by fingerprint months later — which is the part a plain Error enum can't do, since it dies with the process.

What does your chain look like today? If you're already rolling your own, the useful split is: do you actually need the CI/baseline/history parts, or just serialization + stable codes? That'd tell me whether the lifecycle framing is earning its keep for you or whether I've over-built it.

1

u/cybercore_sh 7h ago

Two of my posts on this sub have been removed under Rule 6. Both times the reason given was "code dump."

The mods are right that it's a blanket rule. That's the problem. A blanket rule gets applied to things it wasn't written for, and when it does, the only feedback you get is a tombstone. Nobody in this thread is going to read "thanks for the launch announcement" a second time, and nothing about that outcome is useful to anyone.

I asked three direct questions about design tradeoffs in a field I work in. Two posts in three weeks, both deleted. I don't have another venue with this audience, and I don't have a way to change the rules. What I do have is the observation that a community which removes every launch post also removes every launch post worth reading, and the developers who would have written them don't come back.

Rule 6 exists because low-effort posts are noise. The fix for that isn't deletion with no thread left behind — it's closing the thread for the poster and letting the discussion stand. Mine had replies. Those readers lost the context too.

Two posts is enough data to call this a pattern rather than an accident. If it's deliberate, fine, but it should be a visible decision instead of a series of tombstones people argue about afterward.

0

u/cybercore_sh 9h ago

Author here.

Happy to answer anything. If you only have two minutes, the quickest way to see what diagprint does is the interactive demo: edit the config, hit Mutate buffer, then Apply FixPlan, and watch it refuse to write a stale edit.

One question I'd really like answers to: if you maintain a linter, build tool or CLI, what's the biggest thing that keeps you from emitting structured diagnostics (JSON/SARIF) today?

🛠️ project [ Removed by moderator ]