fix: line number support for unity 6.5 and newer

[bitsandfoxes]

Context

In Unity 6.3 and older, when building the game you'd end up with an output folder looking like that

.
├── game-name_BackUpThisFolder_ButDontShipItWithYourGame
│   ├── GameAssembly.dSYM
│   ├── il2cppOutput
│   └── Managed
|        ├ all-the-dlls.dll
|        └ all-the-dlls.pdb
└── game-name.app

The Managed directory would contain all the stripped down .dll and matching .pdb files. Starting with 6.5 the Managed folder contains the .dll only. To get to the .pdb you will need to do a Development build and opt-in to Script Debugging. Not ideal.

What this does

These options provide the UnityLinker with the additional argument --link-symbols.

So starting with Unity 6.5 on top of adding --emit-source-mapping to IL2CPP we need to add this argument when the UnityLinker gets invoked. Since there are no callbacks and the backdoor of AdditionalIl2CppArguments only works for IL2CPP we're putting it on the environment in the pre-build-step to be picked up.

We'll need to find a less brittle way of getting to the debug symbols

Before

After

Testing

We're now also validating that the stack trace on the resulting events coming from the integration tests do have correct line numbers.

[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.}

^{Reviewed by Cursor Bugbot for commit 8b55488. Configure here.}

[cursor]

Cleanup strips pre-existing linker args

Medium Severity

OnPostprocessBuild always runs RemoveLinkSymbolsArgument, so any pre-existing --link-symbols in UNITYLINKER_ADDITIONAL_ARGS is removed even when Sentry did not add it—for example when the flag was already set, line-number support is off, or the build is not IL2CPP. The previous implementation restored the original value only when it had changed the variable.

Additional Locations (1)

• src/Sentry.Unity.Editor/SentryUnityLinkerProcessor.cs#L63-L77

 

^{Reviewed by Cursor Bugbot for commit 8b55488. Configure here.}

[sentry]

Bug: The use of string.Contains and string.Replace for build argument manipulation is not robust and can fail if another argument shares the same prefix, like --link-symbols-extended.
_{Severity: LOW}

Suggested Fix

Instead of using string manipulation, parse the arguments string by splitting it by spaces. Check for the existence of the exact --link-symbols argument in the resulting list of tokens. To remove it, filter it out from the list and then rejoin the tokens with spaces.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/Sentry.Unity.Editor/SentryUnityLinkerProcessor.cs#L76

Potential issue: The code in `SentryUnityLinkerProcessor.cs` uses
`arguments.Contains(LinkSymbolsArgument)` and `arguments.Replace(LinkSymbolsArgument,
"")` to manage the `--link-symbols` build argument. This substring-based matching is
fragile. If a future Unity version introduces a related argument like
`--link-symbols-extended`, the current logic would fail. The `AddLinkSymbolsArgument`
function would incorrectly skip adding the argument, and `RemoveLinkSymbolsArgument`
would corrupt the existing argument by removing the `--link-symbols` prefix, leaving an
invalid `"-extended"` fragment. This could lead to silent build configuration errors.

Also affects:

• src/Sentry.Unity.Editor/SentryUnityLinkerProcessor.cs:52~52