C#: Tolerate missing call targets in LogMessageSink #14855
Conversation
|
DCA shows no changes (in the nightly suite). |
|
|
||
| public class C | ||
| { | ||
| public ILogger logger; |
There was a problem hiding this comment.
OOI, which type does Roslyn then assign to this field?
There was a problem hiding this comment.
In this case it's A.ILogger. What's odd is that when we process the field, there's no sign of ambiguity.
There was a problem hiding this comment.
That's also what I don't understand, I would have expected that Roslyn didn't assign any type at all. Or is it perhaps because we just take the first candidate symbol?
There was a problem hiding this comment.
To conclude, we found that there's no ambiguity when processing the field or the reference to the field. But the field's type symbol is actually an ambiguous error symbol.
Yes it will. The issue was found through the lost Let me kick off a DCA experiment to see the changes in Standalone... |
|
DCA shows 86 new |
In the standalone mode, we're automatically adding implicit usings to the compilation. If we detect any web application in the repo, we're adding the asp.net core specific implicit usings, which include
Microsoft.Extensions.Logging. This namespace containsILogger, which is quite a common name, and oftentimes conflict withILoggerinterfaces defined in the repo. As a result, we're facing ambiguities in the standalone extracted compilation, and we end up with an incomplete DB. This PR adjusts theLogMessageSinkclass to work in cases when "logger-like" method calls have no extracted target.