Override Stream.ReadAsync/WriteAsync

[terrajobst]

The rule should flag types derived from Stream that override BeginRead/EndRead or BeginWrite/EndWrite but that don't override ReadAsync or WriteAsync. And it should flag types derived from Stream that override the array-based ReadAsync or WriteAsync but that don't override the Memory-based overloads of the same name. (Potentially the same should be done for the Span-based overloads, but as the array-based Read and Write methods are abstract and thus must be overridden, it's harder to say whether those should be or not.)

Category: Performance

[jeffhandley]

Estimates:

• Analyzer: Medium
• Fixer: Medium

[stephentoub]

Fixer: Medium

I don't think there's anything meaningful a fixer could do here.

[carlossanlop]

I don't think there's anything meaningful a fixer could do here.

@stephentoub maybe the fixer could offer empty overrides for those methods, similar to what CS0534 does for abstract classes:

[carlossanlop]

@terrajobst why should the span-based Read/Write overrides not be suggested as part of this analyzer?

Suggested category: Performance
Suggested severity: Info
Suggested milestone: 6.0

Pending to decide in API review:

• If we want a code fixer that behaves like CS0534 or not.
• If we want to also require the span-based Read/Write to get overriden.

Suggested analyzer behavior:

class MyStream : Stream
{
    // After adding the four BeginRead/BeginWrite EndRead/EndWrite overrides below,
    // the analyzer will trigger a warning suggesting to also override:
    // - The array-based ReadAsync/WriteAsync methods
    // - The memory-based ReadAsync/WriteAsync methods
    // - The span-based Read/Write methods
    public override IAsyncResult BeginRead(byte[] buffer, int offset, int count, AsyncCallback callback, object state)
    {
        return ...;
    }

    public override int EndRead(IAsyncResult asyncResult)
    {
        return ...;
    }

    public override IAsyncResult BeginWrite(byte[] buffer, int offset, int count, AsyncCallback callback, object state)
    {
        return ...;
    }

    public override void EndWrite(IAsyncResult asyncResult)
    {
        ...;
    }

    // Suggested to override
    public override Task<int> ReadAsync(byte[] buffer, int offset, int count, CancellationToken cancellationToken)
    {
        return ...;
    }

    // Suggested to override
    public override Task WriteAsync(byte[] buffer, int offset, int count, CancellationToken cancellationToken)
    {
        return ...;
    }

    // Suggested to override
    public override ValueTask<int> ReadAsync(Memory<byte> buffer, CancellationToken cancellationToken = default)
    {
        return ...;
    }

    // Suggested to override
    public override ValueTask WriteAsync(ReadOnlyMemory<byte> buffer, CancellationToken cancellationToken = default)
    {
        return ...;
    }

    // Suggested to override
    public override int Read(Span<byte> buffer)
    {
        return ...;
    }

    // Suggested to override
    public override void Write(ReadOnlySpan<byte> buffer)
    {
        ...;
    }

    // Everything else below was automatically added by CS0534 because they were all abstract

    public override bool CanRead { get; }
    public override bool CanSeek { get; }
    public override bool CanWrite { get; }
    public override long Length { get; }
    public override long Position { get; set; }

    public override void Flush()
    {
        throw new NotImplementedException();
    }

    // This is one of the methods Immo mentioned
    public override int Read(byte[] buffer, int offset, int count)
    {
        throw new NotImplementedException();
    }

    public override long Seek(long offset, SeekOrigin origin)
    {
        throw new NotImplementedException();
    }

    public override void SetLength(long value)
    {
        throw new NotImplementedException();
    }

    // This is one of the methods Immo mentioned
    public override void Write(byte[] buffer, int offset, int count)
    {
        throw new NotImplementedException();
    }
}

[terrajobst]

Video

• We should scope it to cases is Stream (and not a derived type)
• The rule should flag types that override
  • ReadAsync(byte[]) but that don't override the overload with Memory<T>
  • WriteAsync(byte[]) but that don't override the overload with Memory<T>
• On by default with severity info
• Perf category
• No fixer needed, the default behavior of auto completing override or Ctrl + . Generate overrides is sufficient

[Joe4evr]

Re: A different analyzer that suggests to override certain virtuals in more general cases: I've heard the term "soft-abstract" once or twice to refer to those type of members, so wouldn't it make sense to have that analyzer trigger on a SoftAbstractAttribute marker?

[carlossanlop]

@Joe4evr feel free to write an analyzer proposal in a separate issue for the general case you mentioned.

[carlossanlop]

@Mrnikbobjeff if this is one of the analyzers for which you already had an implementation, let me know so I can assign it to you. Otherwise, it's up for grabs.

[NewellClark]

I would like to be assigned to this issue. I have an implementation almost completed. I should have a pr by Monday.

[danmoseley]

It won't let me assign you for some reason but consider it yours!

[NewellClark]

@danmosemsft thank you. I have a working analyzer, but I've found some violations in dotnet/runtime, which I'm working on fixing. Do you want me to wait until all violations in runtime are fixed? Or should I go ahead and submit the analyzer now?

[carlossanlop]

I've found some violations in dotnet/runtime
Do you want me to wait until all violations in runtime are fixed? Or should I go ahead and submit the analyzer now?

@NewellClark do you mean your new analyzer is finding cases in the dotnet/runtime code? If that's the case, please share a PR with the flagged dotnet/runtime cases fixed. Also please share a PR with your new analyzer code. It would be great if we can review both things in parallel.

[NewellClark]

I've found some violations in dotnet/runtime
Do you want me to wait until all violations in runtime are fixed? Or should I go ahead and submit the analyzer now?

do you mean your new analyzer is finding cases in the dotnet/runtime code?

@carlossanlop Yes, I've found seven violations. I've already submitted two PRs. One of the violations (WebSocketHttpListenerDuplexStream) would be complicated to spanify and additionally is only used internally. I'll provide more details about that one when I submit the analyzer PR. Sorry it's taken me awhile to respond; one of the fix-PRs took longer to get up than I expected.

[carlossanlop]

Thanks for helping with this, @NewellClark . I see you are already getting feedback in the runtime PR. I look forward to reviewing your analyzer PR.

[NewellClark]

Would it be possible to have this issue linked to this pr?

[jeffhandley]

@NewellClark Since the PR is in a different repo, I don't think GitHub will mark it as a linked PR. Cross-referencing as you've done in the PR description and the issue comment here matches what we generally do though.

[wzchua]

Is the issue considered done with dotnet/roslyn-analyzers#4726 merged?