Open sharwell opened 9 years ago
:+1:
:question: How would this work with overloads, will this diagnostic effectively block overloads without a Cancellation token? If that is the case, this is too restrictive. I think calling an overload without a Cancellation should be allowed when there is no CancellationToken available is the scope
:question: How would a default parameter with value CancellationToken.None be handled when there is no other cancellation token available in the scope?
:question: How would this work with overloads, will this diagnostic effectively block overloads without a Cancellation token? If that is the case, this is too restrictive. I think calling an overload without a Cancellation should be allowed when there is no CancellationToken available is the scope
The problem with this is the reason no cancellation token is in scope could be that no one realized it was needed.
:question: How would a default parameter with value CancellationToken.None be handled when there is no other cancellation token available in the scope?
It would be reported as a warning by this diagnostic, and the code fix would treat the fixed code as calling the same method (see the note on equivalence keys in the original post above).
This diagnostic would be reported if a method M is called without providing a
CancellationToken
, and either M or one of its overloads has aCancellationToken
parameter.The code fix for this would attempt to fill in the
CancellationToken
as follows:CancellationToken
(with consideration for context objects as described in #32), the innermost visibleCancellationToken
is passed.CancellationToken.None
.