Request for review: fix for Unicode paths dropping C# issues in Rider

Hi everyone,

I would like to request a review of a PR that fixes C# issues being dropped in Rider on Windows when file or directory paths contain Unicode characters, such as accents.

PR: Fix Unicode path matching by sky-ricardogomes · Pull Request #350 · SonarSource/sonarlint-omnisharp · GitHub

Issue

OmniSharp correctly analyzes files in paths such as:

C:\...\diretório\TipoPrestaçãoColeção.cs

And returns issues for them. However, the issues are later discarded before reaching the Rider client.

The problem is caused by the correlation between OmniSharp’s native Windows file paths and SonarLint Core’s percent-encoded file URIs.

Fix

The PR matches diagnostics to InputFiles through Path and URI APIs, preserving Unicode correctly. It also avoids repeated file system scans while correlating diagnostics.

Regression coverage includes:

  • unit tests for percent-encoded Unicode paths;
  • end-to-end C# analysis of diretório/TipoPrestaçãoColeção.cs, validating that S103 is published to the final engine result.

I would appreciate a review of the approach and any guidance needed to get this fix accepted and released.

Thank you!

Hi. We don’t currently accept direct contributions. Would you be fine with us copying the changes and adding them (potentially with some adjustments) in a separate PR?

Hi Georgii, absolutely! That would be great. Please feel free to copy the changes and adapt them as needed in a separate PR.

I’m happy to provide any additional context or help validate the fix on Windows/Rider with Unicode paths if useful.

Hi. So the bug is actually a bit more simple: the frontend schedules analysis for a file uri that is escaped, the analysis succeedes, but when we try to match back it fails because the java backend converts the file path to uri without escaping it, causing the uri comparison to fail. I will take more time next week to fix it properly: I validated my fix with VSCode, but haven’t checked if it fixes/breaks intellij, which might not be passing escaped uri in the first place)

Thanks for looking into this and clarifying the root cause.

Yes, that matches what I observed: analysis succeeds, but the issue is lost when it is matched back to the original file URI. I have a reproducible setup on Windows/Rider using accented directory and file names, so I’d be happy to test the fix on the IntelliJ/Rider side once you have it ready.

Thanks again!