New rule proposal: Provide CancellationToken in calls about asyncusageanalyzers

[vweijsters]

👍

❓ 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

❓ How would a default parameter with value CancellationToken.None be handled when there is no other cancellation token available in the scope?

[sharwell]

❓ 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.

❓ 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).