{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiak6ct2deaam4ukluamhjermwgkcz3s3e7nrk3ppprzqqrtfcgwza",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mn4dkvp57xh2"
  },
  "path": "/t/parser-error-recovery-in-syn-for-better-ide-support-with-proc-macros/24362#post_2",
  "publishedAt": "2026-05-30T20:36:15.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[async_trait]"
  ],
  "textContent": "Currently when using an attribute proc-macro on some function it is basically impossible to recover from parse errors from `syn` in a reasonable fashion for IDE support, any syntax error causes parsing to fail entirely meaning the proc-macro's entire output is generally just `compile_error!` or it panics. It would be very nice to support doing the proc-macro's transformation on the non-erroneous parts of the input so you can still get reasonable code completion and type hints and other IDE niceties even if the input is incomplete or broken.\n\ne.g. if you have a proc-macro like #[async_trait]:\n\n\n    #[async_trait]\n    pub trait MyTrait {\n        async fn my_fn(&self) {\n            let = self. // currently typing here\n        }\n    }\n\n\n`syn` can't parse that as a `trait` with a `let` that's missing a variable and the initializer is missing a method, so it makes IDE completion much worse. (this could be a relatively mild case since completion on the macro inputs ignoring the proc-macro mostly gives the same results (icr if rust-analyzer does that), other macros do more transformation so completion ignoring the proc-macro give bad results or just nothing at all (which is my experience)).",
  "title": "Parser error recovery in `syn` for better IDE support with proc-macros"
}