search

DotNetAnalyzers / AsyncUsageAnalyzers

Now superseded by Microsoft/vs-threading
https://github.com/Microsoft/vs-threading
Other
121 stars 18 forks source link

New rule proposal: Propagate cancellation tokens #37

Open sharwell opened 9 years ago

sharwell commented 9 years ago

This diagnostic would be reported when CancellationToken.None is explicitly provided in a call, but another cancellation token is available in the current context (see #36 and #32 for comments describing the current context).

The code fix for this would replace the use of CancellationToken.None with the "best" cancellation token as described in the code fix for #36.

vweijsters commented 9 years ago

:+1:

tmaczynski commented 7 years ago

I will implement this analysis.

tmaczynski commented 7 years ago

I think that this analysis should be also triggered if default(CancellationToken) is provided in a method call as it's equal to CancellationToken.None.

sharwell commented 7 years ago

@tmaczynski Yes, that's correct.

tmaczynski commented 7 years ago

I'm hesitating if local fields of type CancellationToken should be considered in this diagnostic or not (current description suggests that they should not), any thought on that?

Also, I think that all CancellationToken parameters, local variables (and possibly, fields) should be suggested by a codefix provider, not only the "best" (innermost) one.

sharwell commented 7 years ago

@tmaczynski I'm not sure for fields. I could see it going either way.

sharwell commented 7 years ago

@tmaczynski Oh, maybe just treat this as a potential context object?