{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigfnac226blxpe623i6hs5srjefxeaysvzrtfvhzc34liamgxpqdq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mn4wlucurkh2"
  },
  "path": "/t/parser-error-recovery-in-syn-for-better-ide-support-with-proc-macros/24362#post_6",
  "publishedAt": "2026-05-31T05:05:58.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "  * For attribute macros and derive macros, if the macro is getting called at all, you know that `rustc` thinks that the item _is_ valid syntax and will not be producing an error. if you then get a `syn` parse error, then you _must_ be in a case where `syn` doesn’t support the syntax `rustc` does, and in that case you had better tell the user that that’s the problem, because `rustc` won’t.\n\n  * For function-like macros that take expressions (or whatever existing syntax applies in the context of the macro call) as input, you can't know whether `rustc` _will_ think your input is valid syntax or not, and it might be the case that if you just produce the input, there won’t be any syntax error and the user will be confused.\n\n\n\n\nIn both of these cases, you can’t be _sure_ that just repeating the input will produce a syntax error. It may, as I said previously, just result in your macro mysteriously having no effect.",
  "title": "Parser error recovery in `syn` for better IDE support with proc-macros"
}