Skip to content

Update vs-threading analyzers to 16.7.53#45628

Merged
sharwell merged 6 commits intodotnet:masterfrom
sharwell:update-threading-analyzers
Jul 9, 2020
Merged

Update vs-threading analyzers to 16.7.53#45628
sharwell merged 6 commits intodotnet:masterfrom
sharwell:update-threading-analyzers

Conversation

@sharwell
Copy link
Contributor

@sharwell sharwell commented Jul 2, 2020

This update brings the IOperation version of these analyzers, with two primary benefits:

  1. For many rules, analysis now includes Visual Basic code
  2. The IOperation analysis is much faster

@sharwell sharwell requested review from a team as code owners July 2, 2020 21:07
@sharwell sharwell requested a review from a team July 2, 2020 21:07
Copy link
Member

@jasonmalinowski jasonmalinowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's one place in FileChangeTracker where the old/broken behavior may have been a feature. I can't quite tell. It depends on whether the old code would have actually thrown or whether AsyncLazy was handling that in some way.

I didn't review the compiler changes, this of course needs a review from @dotnet/roslyn-compiler.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably should be throwing, since this isn't any more valid than the original code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other methods also aren't throwing, so this is just a preservation of the original behavior.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think s_none is only ever used as a sentinel value and any attempt to actually call the AsyncLazy is potentially bad; if this would have thrown before we should replace the body with an explicit throw to maintain that invariant.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like this is used as a sentinel, although it wasn't necessarily intended to be used that way.

/// this file. This field may never be null, but might be a Lazy that has a value of null if
/// we either failed to subscribe over never have tried to subscribe.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fact this doesn't blow up with a null is terrifying. :-/

@sharwell sharwell force-pushed the update-threading-analyzers branch from 5fa68e3 to 2f7223a Compare July 8, 2020 18:48
@sharwell sharwell changed the title Update vs-threading analyzers to 16.7.40 Update vs-threading analyzers to 16.7.53 Jul 9, 2020
End Sub

Private Function CompileNamespaceAsTask(symbol As NamespaceSymbol) As Task
Private Function CompileNamespaceAsync(symbol As NamespaceSymbol) As Task
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📝 This rename is the same one we applied for C# in a previous PR

@sharwell
Copy link
Contributor Author

sharwell commented Jul 9, 2020

@dotnet/roslyn-compiler for reviews

End Try
End Function

<SuppressMessage("Style", "VSTHRD200:Use ""Async"" suffix for async methods", Justification:="'Async' refers to the language feature here.")>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why an attribute rather than #Disable Warning?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. It's one line instead of two (the #Disable Warning would still go on this line, but then it would require another line after the method header)
  2. Easy to include the rationale

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The suppression is only needed in source, not from metadata.


In reply to: 452462415 [](ancestors = 452462415)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SuppressMessage is a conditional attribute. I don't believe we are defining CODE_ANALYSIS in our production builds so both forms would be source-only suppressions.

Copy link
Contributor

@cston cston left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Compiler changes LGTM.

// Example: https://github.com/dotnet/roslyn/issues/24124
#pragma warning disable VSTHRD114 // Avoid returning a null Task (False positive: https://github.com/microsoft/vs-threading/issues/637)
return null;
#pragma warning restore VSTHRD114 // Avoid returning a null Task
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the value in running the analyzer on this code base? This code never executes in the context of VS. I don't see why we should be following VS threading rules here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't a naming pattern violation though, it's a functional rule.

Copy link
Contributor Author

@sharwell sharwell Jul 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have to use this rule, but I believe we would generally agree it is correct and not specific to VS code. In most cases, if someone returns null from a Task-returning method, they actually meant to return Task.FromResult<T>(null).

Also, this bug will be fixed so the rule will not run on #nullable enable code (since it duplicates Nullable Reference Types there).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't a naming pattern violation though, it's a functional rule.

I got mixed up thinking this comment was a reply to #45628 (comment). Previous reply has been replaced by a new one.

@sharwell sharwell merged commit d7de299 into dotnet:master Jul 9, 2020
@ghost ghost added this to the Next milestone Jul 9, 2020
@sharwell sharwell deleted the update-threading-analyzers branch July 9, 2020 23:36
@JoeRobich JoeRobich modified the milestones: Next, 16.8.P1 Jul 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants