Update Microsoft.CodeAnalysis.NetAnalyzers to 3.3.0-beta3.20407.4 #40560
Conversation
stephentoub
force-pushed
the
updateanalyzers
branch
from
3d1529e
to
f2fd11b
Compare
stephentoub
force-pushed
the
updateanalyzers
branch
from
f2fd11b
to
ecf064a
Compare
| @@ -112,6 +113,8 @@ | |||
| <Rule Id="CA1834" Action="Warning" /> <!-- Consider using 'StringBuilder.Append(char)' when applicable. --> | |||
| <Rule Id="CA1835" Action="Warning" /> <!-- Prefer the 'Memory'-based overloads for 'ReadAsync' and 'WriteAsync' --> | |||
| <Rule Id="CA1836" Action="Info" /> <!-- Prefer IsEmpty over Count --> | |||
| <Rule Id="CA1837" Action="Warning" /> <!-- Use 'Environment.ProcessId' --> | |||
| <Rule Id="CA1838" Action="Warning" /> <!-- Avoid 'StringBuilder' parameters for P/Invokes --> | |||
There was a problem hiding this comment.
@stephentoub, are there side-effects of using SB with P/Invokes? I have learned the opposite of this rule as a good practice (use SB over IntPtr whenever we need to access the stringly contents in managed code right away). 😁
There was a problem hiding this comment.
From a convenience perspective, StringBuilder in P/Invokes is fine; it makes various operations easier. From a performance perspective, you can almost always do better. Depending on the use, marshalling a StringBuilder can incur multiple copies and allocations, both managed and native. We've made it better in core than it used to be, but even so we've systematically stomped out all usage of it in P/Invokes in the core libraries... the ones in this PR are the last ones remaining, and enabling the rule will help lock that in.
ghost
locked as resolved and limited conversation to collaborators
cc: @bartonjs, @elinor-fung, @AaronRobinsonMSFT