Location.GetMappedLineSpan returns file path with forward slash as directory separator

[csaba-sagi-sonarsource]

Version Used: 4.6.0

Steps to Reproduce:

1. Call Location.GetMappedLineSpan for a SyntaxNode that will map back to a different file.
2. Even if the original file on disk has backslashes as a directory separator (windows environment) the returned path will contain forward slashes.

Why this is a problem?

When an issue is reported with this path containing forward slashes, Visual Studio will not show the path correctly. It will instead point to the project file.

Expected Behavior:

The directory separator matches the one of the operating system.

Actual Behavior:

The directory separator is not matching the one on the operating system.

This behaviour was reproduced while analyzing razor generated files.

[jcouv]

I checked our GetMappedLineSpan tests and we have scenarios where a path uses backslashes and the mapped path also uses backslashes. So there must be something more involved in your repro...
What is in your pathmap file? I suspect it uses forward slashes for "mapped to" paths. That would explain the behavior you're observing.

[csaba-sagi-sonarsource]

@jcouv,

I don't provide an additional pathmap.

After digging a bit deeper I have seen the following:

When I run a dotnet build of the project, the line directive is the following:
#line 8 "C:\SomeFolder\Razor.Analyzers\Razor.Analyzers.Razor.Net7.Example\Pages\Error.cshtml"

While the line directive is different during the design time build:
#line 8 "C:/SomeFolder/Razor.Analyzers/Razor.Analyzers.Razor.Net7.Example/Pages/Error.cshtml"

So, if GetMappedLineSpan gets the information from the #line directive which it does, then the problem is not in GetMappedLineSpan. I guess it either comes from the razor source generator or from visual studio (or wherever the design time builds logic is).

So, I guess this issue as is should be moved to a different component (with a different name). Can you please help me to choose the correct component?

[jcouv]

@csaba-sagi-sonarsource Thanks for the additional information. The question is what caused the razor source generator to produce different outputs in design-time vs. build-time scenarios.
Tagging @jasonmalinowski in case he can advise on how to capture binary logs to figure this one out.

[tmat]

I'd definitely not expect this. The paths in the generated file should be exactly the same between design-time and command line builds. Seems like a bug.

[jasonmalinowski]

If this is the design-time build then a binlog won't happen anyways since those files never hit disk (or exist in the command line build in the first place!) But razor repo is right for this.

[chsienki]

Hmm, this is interesting, because the compiler isn't actually controlling those paths. We just print out whatever the syntax tree path is.

For the source generator, the compiler 'owns' the project items, and we use the file system path, which is passed into the syntax tree. For design time the project items are 'owned' by the tooling. For reasons unclear to me they are normalized to use forward slashes.

@davidwengier Do you have any insight into why the file paths are normalized in the razor project system? I could feasibly un-normalize the file paths in design time, but want to understand it a little more before we do that. Are the paths actually used for anything? I would have assumed they were an opaque identifier?

[davidwengier]

Not sure I know the full story of "why" I'm afraid, normalizing paths is just something Razor does and sometimes it causes issues, and there are a couple of places where we un-normalize them to "work around issues" too.

The file paths are definitely used though, as the unique identifier for a document. I wonder if its related to the fact that at design time there are two worlds that are competing: for open documents, the language server is in charge and all talk of documents is done via Uri, and for closed documents, in VS at least, the VS-side components are in charge so would naturally use file system paths. Or alternatively, maybe its to allow LiveShare to work, where server and client could be on different OSes? Either way, I wouldn't be surprised if there aren't better approaches, I don't think its been looked at.

[chsienki]

Ok, thanks for the info.

As we're fairly late in a few different release cycles, and I am a chicken, I'm going to just unnormalize the paths in design time, but I'll open an issue to track us resolving this correctly across everything. We're going to have to fix it whether we like it or not if we get rid of runtime/design time split.

[chsienki]

Closed via #9354