Fix 'Use Index' and 'Use Range' analysis for projects with multiple definitions#43205
Fix 'Use Index' and 'Use Range' analysis for projects with multiple definitions#43205sharwell merged 5 commits intodotnet:masterfrom
Conversation
src/Workspaces/SharedUtilitiesAndExtensions/Compiler/Core/Extensions/CompilationExtensions.cs
Show resolved
Hide resolved
|
Could you mark any interesting tests that needed to actually change behavior? |
The only significant one which wasn't part of the final commit was changed after I filed #43202. |
| // Otherwise, try to get the unique accessible type with this name from a reference | ||
| if (type is null) | ||
| { | ||
| foreach (var module in compilation.Assembly.Modules) |
There was a problem hiding this comment.
foreach (var module in compilation.Assembly.Modules) [](start = 16, length = 52)
@sharwell I believe traversing all modules here is an overkill. Added modules cannot successfully resolve an assembly reference unless the assembly is given to the compilation as a reference. In which case, it will be among referenced assemblies of the SourceModule. More over, it looks like traversing all modules is likely to cause this API to fail due to a false ambiguty. For example, two modules reference the same assembly defining the target type, the type will be found twice. It looks like that will be treated as a conflict.
| if (currentType is null) | ||
| continue; | ||
|
|
||
| switch (currentType.GetResultantVisibility()) |
There was a problem hiding this comment.
switch (currentType.GetResultantVisibility()) [](start = 24, length = 45)
@sharwell Consider if using Compilation.IsSymbolAccessibleWithin for "visibility" check is more appropriate alternative.
No description provided.