FAR missing occurrences in Shared Project Files #3351
Comments
|
FYI @dpoeschl |
|
This repros without syncing to the specified commit by using members from the same type, like |
|
The scope of this problem is limited to documents linked into projects with the same assembly name. In the given example, The actual results from AbstractFindReferencesService.FindReferencedSymbolsAsync are incorrect:
The first three lines show the projects containing the three definitions, and things look good there. The next three lines show the projects containing the first reference to each of these symbols, and you can see the |
|
IIRC, there are numerous cases where we unify projects based on assembly name. |
|
Note: Please also verify and test related bug(s) #3352 when resolving this bug. |
|
Note: Added one more customer scenario to the related bug mentioned above (Asp.Net vNext Applications). |
|
Tagging @jasonmalinowski. We should consider doing something here to support the Asp.NET 5.0 cases) |
|
@Pilchie: hah, somebody testing my csproj -> xproj prototype immediately hit this bug. Already debugged it a bit yesterday, will fix today. |
|
Verify internal bug 162818 when verifying this fix. |
|
I've verified internal bug 162818. |
Before this change, if you had two projects that had the same assembly name, you might get weird results from find references. Internally it used assembly name as a cache key for dependent projects, and so as long as the two projects with same assembly name had different dependent projects, we might not actually search all the projects we need to in your solution. Further, if you had the same linked file in both of these projects, we wouldn't search all projects that had it linked. This was because the LinkedFileReferenceFinder would correcty find all the symbols in linked projects, but the engine would then dedup the list calling those equal because once again the assembly names were equal. We make a decision here that when searching for symbols, symbols from source should never be deduplicated across projects that define them, but we will still merge metadata symbols as a single referenced symbol. There is an argument that we should also split up metadata symbols as well, but many consumers might find it very surprising that suddenly they get N referenced symbols in the result if there are N projects in the solution. For now, we'll maintain the result there. Fixes issue dotnet#3351.
|
Fixed by #8096. |
sawInvalidIdentifier = !IsIdentifier(identifier);), Find All References ofIsIdentifier.Expected: 3 defs, each with 4 refs
Actual: 3 defs, two with 4 refs each, one with 0 refs
The text was updated successfully, but these errors were encountered: