{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibdrtr4ket7bxcckxodrnog5sucv7yvpdd3takvivx3hbulxujjyy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfmprgcphye2"
  },
  "path": "/t/custom-cargo-command-to-show-only-errors-avoid-setting-rustflags-every-time/24032#post_14",
  "publishedAt": "2026-02-24T16:24:08.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "kpreid:\n\n> But is it in general a compiler bug every time the compiler recovers from an error in an incorrect (according to the user's intent) fashion?\n\nYes. It should either recover in a way that captured user intent, or in a way that silences subsequent errors (_potentially_ hiding subsequent desired errors). Any other behavior is unintended.\n\n> Tangentially: does the same logic apply to parser recovery? I occasionally see \"mismatched braces\" error pointing very far from the actually mismatched brace.\n\nYes. If you have repro cases we can try to figure out how to account for those cases better. The problem is that by the time the parser is doing its things the Token Tree was already constructed. The error happens at the point the mismatch was detected, not where it happened. The parser keeps track of opened but unclosed delimiters to point at, but that logic might be incomplete, if you're seeing cases where we don't point at the right place already.",
  "title": "Custom Cargo Command to Show Only Errors (Avoid Setting RustFLAGS Every Time)"
}