New rule proposal: Provide CancellationToken in calls

[sharwell]

This diagnostic would be reported if a method M is called without providing a CancellationToken, and either M or one of its overloads has a CancellationToken parameter.

The code fix for this would attempt to fill in the CancellationToken as follows:

1. If a local variable or parameter provides a CancellationToken (with consideration for context objects as described in New rule proposal: Async methods should have a CancellationToken parameter #32), the innermost visible CancellationToken is passed.
2. Otherwise, pass CancellationToken.None.

⚠️ Separate equivalence keys should be used for the code fix for the case where the updated call still calls the same method, and the case where the updated call is to a different overload of the method.

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