Confusing behaviour with types that have both generic and non-generic versions

[hankovich]

I ran into a couple of weird issues at source.dot.net:

1. It's impossible to find IEnumerable<T> (I tried with and without namespace, with and without namespace assembly name etc),
2. In the List<T> page both links to IList<T> and IList point to the same page (IList<T>),
3. In the IList<T> page link to ICollection<T> points to the non-generic ICollection,
4. A lot of references to IEnumerable<T> (example) point to error page (which says Don't use this page directly, pass #symbolId to get redirected.)

All pointed issues are applicable for all interfaces that have both generic and non-generic versions (IEnumerator, IEqualityComparer etc).

The issue is probably related to #179.

[alexperovich]

This looks like a problem caused by both IEnumerable and IEnumerable<T> being in files with the same name. They are both in IEnumerable.cs, just in different folders. It appears that the folder structure gets flattened by SourceBrowser and causes problems.

[KirillOsenkov]

Interesting, indeed there's some weirdness here.

On https://referencesource.microsoft.com it works better. Compare:
https://referencesource.microsoft.com/#q=IEnumerable
https://referencesource.microsoft.com/#q=IEnumerable%3C

I usually search for generic types by appending the <, such as IList<, so there's nothing in SourceBrowser itself that would prevent this from working.

[KirillOsenkov]

Alex, you're correct, it does appear that the file hierarchy is flattened, but why is this happening? SourceBrowser should be preserving the hierarchy within a project.

[KirillOsenkov]

Oh, I'm guessing .shproj (shared projects) are involved. https://github.com/dotnet/runtime/tree/4c92aef2b08f9c4374c520e7e664a44f1ad8ce56/src/libraries/System.Private.CoreLib/src

We might not have the best in the world support for shared projects honestly. Worth looking into this.

[alexperovich]

its not technically a shproj, because its been processed with my binlig -> sln translation stuff, but all the files that are flattened are in the csproj like this: ..\..\libraries\System.Private.CoreLib\src\System\Activator.cs so I bet thats the problem. Its showing up as a "linked" file without any link.

[alexperovich]

I can share the full solution if it would be helpful, but its somewhat large.

[KirillOsenkov]

ah, yes, linked files from outside the project cone would be flattened, that explains it. We should probably try and respect the metadata to properly recreate the "virtual" subdirectory of linked files.

[alexperovich]

In this case there is no metadata, because the project file is a recreation based on the compiler invocation. Roslyn respects Link metadata if it exists IIRC.

[alexperovich]

I might be able to.... reconstruct the link metadata somehow, but I don't know a way to do that in general. I could make the tool find a common prefix for all the files and use that as the "root" and produce Link metadata from that, but it probably wouldn't work perfectly. It might still work "good enough" to prevent same-name files from clashing.

[KirillOsenkov]

I think if you have the path for the csproj (which you should have) then each .cs path is relative to the .csproj. You can fiddle with relative paths and compute the Link metadata for those outside the project cone.

We can brainstorm this together if you like.