{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiajmem5w5f6sfrgtzpxnzdx7jellgf6yi3k6fliegm3tcq2um6pdi",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mng2j25bfjd2"
  },
  "path": "/t/parser-error-recovery-in-syn-for-better-ide-support-with-proc-macros/24362?page=2#post_21",
  "publishedAt": "2026-06-03T20:51:07.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "I meant that in terms of diagnostics ultimately shown to the user, not proc macro developer experience. I solved that with precedence to emulate Rustc's behaviour in my crates.\n\nI think the `proc_macro2_diagnostic`-API is a bit sketchy for _recovering_ parsers too though, since you'd have to smuggle errors in the \"warning\" variant to do so.\nI'd have to see some example code, but I think having to aggregate manually also makes it a bit more verbose than my approach of just adding `, errors` to nested parser calls when parsing a sequence of recovering elements. Ymmv on whether you'd like to make forwarding or local handling of side-channel errors easier, of course. I personally find the former easier since, with precedence levels, I don't need local diagnostics handling at all in my macros.\n\n**Edit:** I missed that the `Warning` variant emits when `Try`d.\nHm, not a huge fan of subtle side effects like that, to be honest, but that's personal preference.",
  "title": "Parser error recovery in `syn` for better IDE support with proc-macros"
}