NonCopyable structs attribute and analyzer

[jkotas]

Background and Motivation

New high-performance APIs are often exposed as structs to avoid GC heap allocation. Callers of such APIs have to be careful to avoid creating accidental copies of the struct. Failure to do so can lead to correctness or security issues. We need a capability to prevent or detect this class of bugs at build time.

ValueStringBuilder is an example of an API where creating accidental copy is a potential security bug: #25587 (comment)

Existing implementations of similar analyzers:

• https://github.com/ufcpp/NonCopyableAnalyzer
• Implement RS0042 (Do not copy value) roslyn-analyzers#3420

Proposed API

Promote https://github.com/ufcpp/NonCopyableAnalyzer developed by @ufcpp into .NET platform API so that it can be used by the platform itself.

 namespace System
 {
+    [AttributeUsage(AttributeTargets.Struct)]
+    public class NonCopyableAttribute : Attribute
+    {
+    }
 }

Usage Examples

[NonCopyable]
public struct ValueStringBuilder
{
...
}

ValueStringBuilder vsb = new ValueStringBuilder();
f(vsb); // Error. ValueStringBuilder must by passed by reference

Alternative Designs

Full C# language feature. The difficulty in doing so is described in https://blog.paranoidcoding.com/2019/12/02/borrowing.html .

Risks

Corner cases that are missed by the analyzer, e.g. use of reflection.

[jkotas]

More context dotnet/designs#189 (comment)
cc @GrabYourPitchforks

[sharwell]

The one feature that I really wish the analyzer supported is "allow copies to read-only locations". This configuration would allow non-mutating operations to run against snapshot copies, which broadens applicability of [NonCopyable] from strictly non-copyable types to more general usage on mutable value types to avoid mutating a copy that will not be observed.

[jkotas]

allow copies to read-only location

It would not work for ValueStringBuilder and other similar cases where the struct holds manually managed resource.

[bartonjs]

The one feature that I really wish the analyzer supported is "allow copies to read-only locations"

That wouldn't solve the ValueStringBuilder problem, though. At least, not if it uses ArrayPool.

• A VSB gets into a given state.
• A readonly copy gets created for the current state.
• The writable version calls Append
  • VSB needs to grow, so it rents a new array, copies the contents, returns the old array.
• State sanity check, the copy still looks like it did prior to the call to Append.
• Something else happens
  • The something else rents an array, gets the recently returned array, and uses it.
• State sanity check fails.
  • The copy had a reference to the returned and re-rented array. That array's contents have changed.

Even without ArrayPool, overwrites would be visible on the copy (writing through into arrays), but appends wouldn't (changing fields).

I don't doubt that readonly copies can make sense in some cases, but they wouldn't solve this one, and feel like they're a weird knifes-edge in general.

[sharwell]

It would not work for ValueStringBuilder and other similar cases where the struct holds manually managed resource.

Note that my comment was more for wishing we could do this:

[NonCopyable(AllowCopyToReadOnlyLocation = true)]

Types like ValueStringBuilder would use the default value false, but many value types which only need to be non-copyable during an initial mutable phase could leverage this for improved usability.

[sharwell]

On a totally separate note, this feature is going to be extremely difficult to implement without the compiler exposing some sort of an API specifically to analyze value copies. Even with the conservative approach used by RS0042 (fail on any unrecognized construct) we've found a significant number of holes.

[tannergooding]

CC. @jaredpar. Would this conflict with or be superseded by any work being done on the language side?

[sharwell]

I'm not aware of LDM work on this, but will let @jaredpar provide a more definitive answer. I stopped pushing on this as a language feature primarily due to questions surrounding the value of #50389 (comment) (the compiler would not be able to provide this value through built-in language features, but an analyzer could account for it as long as an analyzer API for value copies existed).

I believe the ideal handling here would be a general analyzer callback for any copy in IL (without any consideration for the type being copied), and the analyzer for this feature would filter as necessary.

[jaredpar]

Coulpe of questions:

• Do you all have a fleshed out set of rules for NonCopyable or ValueStringBuilder that you want to enforce with this analyzer? Couple that seem to apply:
  • Disallowed as generic arguments
  • Disallow [NonCopyable] struct as a field of standard struct
  • Disallow as locals in an async method or iterator
  • etc ...
• Generally non-copyable types end up desiring to have move semantics. Essentially copying is bad but move is okay. Do you all desire this property here and if so how do you all define what constitutes a "move". Consider that returning a local from a function is likely a safe "move" operation.
• Are multiple mutable references okay here? Basically can you do the following when vsb represents a [NonCopyable] struct: SomeMethod(ref vsb, ref vsb).
• Are [NonCopyable] types forced to be ref struct or can they be simple struct? If the latter then that implies tearing is okay (is that the case)?

On a totally separate note, this feature is going to be extremely difficult to implement without the compiler exposing some sort of an API specifically to analyze value copies.

I agree. There are a lot of subtle cases where the compiler does or does not copy a value. It's possible to write conservative analyzers which flag more copies than exist but are unlikely to miss any. It's hard to write one that exactly matches the behavior of the compiler though.

It's also important to know if we care about invisible copies. There are several places where the compiler will introduce copies in synthesized members that are invisible to the customer but do constitute copies of the values (consider the places where the compiler introduces thunks to meet some metadata contract and hence has to pass values through the thunk). Do this matter for this feature? My assumption is no but wanted to check.