…#77102)

For VSCode we were adjusting information diagnostics severity so that
they would be reported as hints. We are moving this behavior to the
client and allowing users to opt-in.

Client-side PR: dotnet/vscode-csharp#7984

Part of dotnet/vscode-csharp#6723

Our RPC mechanism to the build host is a simple one: we send JSON
payloads that are formatted as a single textual line, similar to
other methods. We did the writing to the build host via a TextWriter,
and called Flush() at the end to ensure that everything is written
to the other end, otherwise things might deadlock if we wait for the
server to reply to something that's not coming.

We recently switched the communication over to named pipes, which
have a bit of a subtle problem here: with PipeStream, Flush() doesn't
do anything, but it will check the pipe is still connected and throw
if it's not. This had a problem during shutdown: we might write to the
pipe, and the other side will see the shutdown request, respond, and
close, before that Flush() call could ever happen. And once it did,
we'd then throw an exception becase the other end did exactly what
wanted it to!

I could special-case the handling of pipes in the RPC code, but there's
no reason to allow the use of arbitrary streams here. Instead, it's
best to just update the tests to also use named pipes (which means we're
better testing what we're doing in real code), and it also means we can
dispense of flushing entirely. Unfortunately TextWriter gives no
way to disable flushing that I can see, so I also dispose of TextWriter
and just write to the PipeStream directly.

Fix dotnet#77040

* add main to release/dev18.0 flow

* add workflow-dispatch

…ence-packages build 20250210.2

Microsoft.SourceBuild.Intermediate.source-build-reference-packages
 From Version 10.0.607901 -> To Version 10.0.611002

* Detect data section string literal hash collisions

* Move check into GetOrAdd

* Remove VB error

* Remove test only option from equality

* Truncate the string in the error message

* Update the spec

* Update the spec

…ence-packages build 20250130.4 (dotnet#76985)

Microsoft.SourceBuild.Intermediate.source-build-reference-packages
 From Version 10.0.607901 -> To Version 10.0.608004

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

* Add source package

* Polyfills

* Move ExceptionUtilities and Contracts to Microsoft.CodeAnalysis namespace

* Move ExceptionUtilities to Contracts source packages

* Move Contract to Contracts source packages

* Move NonCopyable, NonDefaultable attributes to Microsoft.CodeAnalysis namespaces

* Move NonCopyableAttribute and NonDefaultableAttribute to Contracts source package

* Exclude Contract from core compiler

Discovered in dotnet#76141

The other test for this was disabled (feature not currently used in
vscode), so this regression slipped in.

Our RPC mechanism to the build host is a simple one: we send JSON
payloads that are formatted as a single textual line, similar to other
methods. We did the writing to the build host via a TextWriter, and
called Flush() at the end to ensure that everything is written to the
other end, otherwise things might deadlock if we wait for the server to
reply to something that's not coming.

We recently switched the communication over to named pipes, which have a
bit of a subtle problem here: with PipeStream, Flush() doesn't do
anything, but it will check the pipe is still connected and throw if
it's not. This had a problem during shutdown: we might write to the
pipe, and the other side will see the shutdown request, respond, and
close, before that Flush() call could ever happen. And once it did, we'd
then throw an exception becase the other end did exactly what wanted it
to!

I could special-case the handling of pipes in the RPC code, but there's
no reason to allow the use of arbitrary streams here. Instead, it's best
to just update the tests to also use named pipes (which means we're
better testing what we're doing in real code), and it also means we can
dispense of flushing entirely. Unfortunately TextWriter gives no way to
disable flushing that I can see, so I also dispose of TextWriter and
just write to the PipeStream directly.

Fix dotnet#77040

…g twice

dotnet#77335)

* Update dependencies from https://github.com/dotnet/source-build-reference-packages build 20250224.2

Microsoft.SourceBuild.Intermediate.source-build-reference-packages
 From Version 10.0.611901 -> To Version 10.0.612402

* Update dependencies from https://github.com/dotnet/source-build-reference-packages build 20250225.2

Microsoft.SourceBuild.Intermediate.source-build-reference-packages
 From Version 10.0.611901 -> To Version 10.0.612502

* Update dependencies from https://github.com/dotnet/source-build-reference-packages build 20250227.2

Microsoft.SourceBuild.Intermediate.source-build-reference-packages
 From Version 10.0.611901 -> To Version 10.0.612702

* Update dependencies from https://github.com/dotnet/source-build-reference-packages build 20250228.4

Microsoft.SourceBuild.Intermediate.source-build-reference-packages
 From Version 10.0.611901 -> To Version 10.0.612804

* Update dependencies from https://github.com/dotnet/source-build-reference-packages build 20250303.3

Microsoft.SourceBuild.Intermediate.source-build-reference-packages
 From Version 10.0.611901 -> To Version 10.0.615303

---------

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

…ing twice in a MAS file. (dotnet#77405)

Fixes dotnet#77382

Improve performance of SyntaxReplacer.ReplaceNode

This should allow better performance when replacing nodes. I've noticed overrides completion commit profiles as indicating a large amount of time/memory spent in their ReplaceNode calls. (about 18% of CPU time and 20% of memory allocations spent within CommitManager.TryCommit are attributable to ReplaceNode calls)

See PR for more details on the performance benefit the speedometer achieves with this change.