Fix StreamWriter keeps working after being disposed if leaveOpen: true is used

[ViveliDuCh]

Fixes #89646

Description

StreamWriter created with leaveOpen: true silently continues accepting writes after Dispose() / DisposeAsync() instead of throwing ObjectDisposedException. StreamReader with the same flag correctly throws.

The root cause is in CloseStreamFromDispose: the _disposed = true assignment was gated behind if (_closable && !_disposed), where _closable is false when leaveOpen: true. This meant _disposed was never set to true, so ThrowIfDisposed() never fired.

var ms = new MemoryStream();
var sw = new StreamWriter(ms, leaveOpen: true);
sw.Write("Hello");
sw.Dispose();
sw.Write(" World"); // No exception thrown — bug

Fix

Restructured CloseStreamFromDispose so _disposed = true, _charLen = 0, and base.Dispose(disposing) execute unconditionally in the finally block, while _closable now only gates _stream.Close(). This mirrors the pattern already used by StreamReader in StreamReader.Dispose(bool):

 private void CloseStreamFromDispose(bool disposing)
 {
-    if (_closable && !_disposed)
+    if (!_disposed)
     {
         try
         {
-            if (disposing)
+            if (_closable && disposing)
             {
                 _stream.Close();
             }
         }
         finally
         {
             _disposed = true;
             _charLen = 0;
             base.Dispose(disposing);
         }
     }
 }

NullStreamWriter (backing StreamWriter.Null) is not affected — it overrides both Dispose(bool) and DisposeAsync() as no-ops and never calls CloseStreamFromDispose.

Testing

Added tests to existing test files (no new files, no csproj changes needed):

• CloseTests.AfterDisposeThrows_LeaveOpenTrue : sync Dispose with leaveOpen: true.
• StreamWriterTests.DisposeAsync_LeaveOpenTrue_ThrowsAfterDispose : async DisposeAsync with leaveOpen: true
• StreamReaderTests.ObjectDisposedExceptionDisposedStream_LeaveOpenTrue: confirms StreamReader parity.

Full System.IO.Tests suite: 1712 tests, 0 regressions (1 pre-existing unrelated failure in MemoryStream_CapacityBoundaryChecks).

[Copilot]

Pull request overview

Fixes a StreamWriter disposal bug where leaveOpen: true prevented the writer from transitioning to a disposed state, allowing post-Dispose() / DisposeAsync() writes to proceed instead of throwing ObjectDisposedException. This aligns StreamWriter behavior with StreamReader and expected .NET disposed-object semantics.

Changes:

• Update StreamWriter.CloseStreamFromDispose so _disposed is set (and internal state is cleared) regardless of leaveOpen, while _closable only gates closing the underlying stream.
• Add regression tests for sync Dispose() + leaveOpen: true and async DisposeAsync() + leaveOpen: true.
• Add a parity test confirming StreamReader throws after disposal when leaveOpen: true.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
src/libraries/System.Private.CoreLib/src/System/IO/StreamWriter.cs	Ensures StreamWriter becomes disposed even when leaveOpen: true, preventing further writes after disposal.
src/libraries/System.Runtime/tests/System.IO.Tests/StreamWriter/StreamWriter.DisposeAsync.cs	Adds regression coverage for DisposeAsync() with leaveOpen: true throwing on subsequent writes.
src/libraries/System.Runtime/tests/System.IO.Tests/StreamWriter/StreamWriter.CloseTests.cs	Adds regression coverage for Dispose() with leaveOpen: true throwing on subsequent operations.
src/libraries/System.Runtime/tests/System.IO.Tests/StreamReader/StreamReaderTests.cs	Adds a test asserting StreamReader throws after disposal when leaveOpen: true (behavior parity reference).

[stephentoub]

This is likely to break someone. I think it's ok to make, as we say that use-after-dispose is erroneous. But we might want to consider marking it as a breaking change.

[ViveliDuCh]

@dotnet/compat This fix changes StreamWriter to throw ObjectDisposedException after Dispose() when leaveOpen: true. Previously, writes silently succeeded. This aligns with StreamReader behavior and standard IDisposable semantics. We believe this is a Bucket 2 behavioral change with low practical risk since use-after-dispose is always erroneous.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[adamsitnik]

LGTM, thank you @ViveliDuCh !

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

[jozkee]

I'll defer to the team on whether to take this breaking change. I've said my piece.

[jozkee]

This reactive fix hints at me that this breaking change is likely going to make some considerable noise. Are we OK with prioritizing correctness over compatibility?

#89646 use-after-dispose is harmless and even ourselves have taken a dependency on it for 12+ years, not counting when this was added in netfx.

[jozkee]

Also, Preview 3 will snap soon; it would be good to include this change and find out how many users are affected.

[jozkee]

Aside from merging this for gathering feedback,

I'm not confident in shipping this. While the analysis is thorough and appreciated, I can see ways in which customers will yell at us for breaking this. For example, if someone has a legacy 3rd-party dependency (say an unmaintained NuGet package), this will break them without a way to work around it, we'd then have to introduce an AppContext switch to unblock them. So this would block upgrading/adoption more than what it fixes.

Given that nobody is actively asking for this fix, the risk/reward doesn't justify the change IMO. The motivation behind #89646 was to generate this kind of conversation, which I appreciate but now I'm convinced that doing it is not the right thing.

@dotnet/compat et. al. thoughts?

[stephentoub]

Given that nobody is actively asking for this fix, the risk/reward doesn't justify the change IMO.

This was ultimately my feedback to @ViveliDuCh offline as well.