feat(r8): Propagate class-level synthesized flag to members

[romtsn]

Part of #40

Propagates the class-level is_synthesized flag (from # {"id":"com.android.tools.r8.synthesized"} headers) to all members of that class. This allows callers (e.g. Sentry symbolicator) to filter out synthetic frames via method_synthesized() — this crate intentionally keeps them in the output.

Changes

• mapper.rs / cache/raw.rs: OR class-level and method-level synthesized flags when resolving mappings
• tests/r8-synthetic.rs: 7 tests covering lambda methods, lambda with inlining, and moved synthesized info — including both mapper and cache paths, stacktrace remapping, and method_synthesized() flag verification

[loewenheim]

We could filter them out in remap_stacktrace, yeah. For the remap_stacktrace_typed I would leave it as it is.

[romtsn]

we keept marking frames as synthesized and don't drop them in this crate. We can close this PR. We could also hide the synthesized frames in the Sentry UI

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[Dav1dde]

High level this makes sense to me to inherit the flag from the class to its members, but there was some prior discussions about how and where to do it, where I am missing a bit of context:

---

we keept marking frames as synthesized and don't drop them in this crate. We can close this PR. We could also hide the synthesized frames in the Sentry UI

What made you change your mind, seemed like it was an option to not do this?

---

Sebastian also mentioned a different place remap_stacktrace, why did you choose this approach?

[romtsn]

@Dav1dde sorry, should've definitely written something to give more context:

We still need to drop them, because users might have their custom stacktrace rules configured, which forcefully mark synthesized frames as in-app, and then those frames can show up in stacktraces completely unrelated to the app resulting in wrong code ownership assignments. So we've made the decision to drop them in sentry/symbolicator altogether, avoiding this situation and aligning with how Google's r8-retrace behaves.

I've repurposed this PR (should've probably closed this and opened a new one) to propagate synthesized classes flag to its members, since we don't operate on the class level, but on the members level in sentry/symbolicator.