Remove unnecessary Console.SetOut

[majocha]

There is some code in fsi and fsc to remember and finally restore the initial Console.Out.

However, the fsc or fsi itself never modifies console streams with Console.SetOut etc.

Modifying a global resource like this can lead to difficult to track errors in hosted multithreaded execution, like parallel testing (#17662).

Maybe there is a reason for this that I don't see?

[github-actions]

⚠️ Release notes required, but author opted out

Warning

Author opted out of release notes, check is disabled for this pull request.
cc @dotnet/fsharp-team-msft

[T-Gro]

IIRC the HostedCompiler was relying on stdout redirection, should only be used for some of the legacy test suites (FsharpQA I think). But FSharpQA still runs here, so that keeps working after your change.

[KevinRansom]

@majocha , @T-Gro --- I'm afraid the savedOut is necessary.

The scenario is this:

• The host application is using a non-UTF8 Encoding, E.g UTF-7 or UTF-32
• The host executes the compilation and passes in the '--utf8output' flag
• This flag changes the Encoding of the Console.Out to UTF which is not what the host app was set to.
• The purpose of the savedOut is to ensure that these changes caused by our compiler do not adversely impact the hosts.

fsharp/src/Compiler/Driver/fsc.fs

Line 276 in 52133d0

if tcConfigB.utf8output then

[KevinRansom]

It also looks as if unused binding analysis didn't find the unused:
let setOutputStreams execute =

I wonder why.

[edgarfgp]

It also looks as if unused binding analysis didn't find the unused: let setOutputStreams execute =

I wonder why.

Might be related to #13849

[majocha]

The scenario is this:

• The host application is using a non-UTF8 Encoding, E.g UTF-7 or UTF-32
• The host executes the compilation and passes in the '--utf8output' flag
• This flag changes the Encoding of the Console.Out to UTF which is not what the host app was set to.
• The purpose of the savedOut is to ensure that these changes caused by our compiler do not adversely impact the hosts.

Thanks @KevinRansom, this is important because it seems in the course of recent changes the test for this got lost.

Also, I'm wondering, maybe just restoring the encoding (if the Out is still the same during dispose) would be less intrusive.

[majocha]

I'm frankly confused about this but I suspect that setting OutputEncoding affects the underlying system level stuff and has no effect when console is redirected?

[psfinaki]

Anything interesting from the git blame? (I can also take a look later in the day)

[KevinRansom]

@majocha ---
the redirection is irrelevant, since there is a scenario where someone writes a .net app that does work and calls into the compiler directly. For example fantomas, or fsc.exe for that matter, although neither of those apps mess with Encoding.

[majocha]

I'll write a test to see what the situation is right now. I understand that from the consumer's pov it's important that fsc writes using the correct encoding according to the given switch and that console encoding is restored afterwards.

[KevinRansom]

It works, but yes a test case in the repo would be useful to ensure that it doesn't get inadvertently ripped out in the future.