ComputeImplementationForInterfaceMember shouldn't perform any validation of the result and shouldn't report any diagnostics for it if the type it is called for doesn't implement the interface, unless the mentioned operations affect resulting symbol.#42405
ComputeImplementationForInterfaceMember shouldn't perform any validation of the result and shouldn't report any diagnostics for it if the type it is called for doesn't implement the interface, unless the mentioned operations affect resulting symbol.#42405AlekseyTs merged 2 commits intodotnet:masterfrom
Conversation
…ion of the result and shouldn't report any diagnostics for it if the type it is called for doesn't implement the interface, unless the mentioned operations affect resulting symbol. Fixes dotnet#42340.
|
@gafter, @dotnet/roslyn-compiler Please review. |
1 similar comment
|
@gafter, @dotnet/roslyn-compiler Please review. |
|
@dotnet/roslyn-compiler Please review a small change, need a second sign-off. |
| #if !DEBUG | ||
| // Don't optimize in DEBUG for better coverage for the GetInterfaceLocation function. | ||
| if (useSiteDiagnostics != null) | ||
| if (useSiteDiagnostics != null && implementingTypeImplementsInterface) |
There was a problem hiding this comment.
Does this make it so we add the useSiteDiagnostics in a release debug build even if implementingTypeImplementsInterface is false?
edit: Looks like I misread the condition above, however it still seems like there might be a behavior inconsistency between debug and release builds. #Resolved
There was a problem hiding this comment.
however it still seems like there might be a behavior inconsistency between debug and release builds.
That behavior difference is not observable, unless there is a bug in the methods called within the if statement. We intentionally stress them in DEBUG. There are other examples where we do extra work in DEBUG for the sake of extra validation.
In reply to: 393223483 [](ancestors = 393223483)
Fixes #42340.