…/interpolated-string

Merge master to features/interpolated-string

…ileScopedNamespaces

Merge main to features/FileScopedNamespaces

…nterpolated-string

Merge main to features/interpolated-string

…nterpolated-string

Merge main to features/interpolated-string

…ileScopedNamespaces

Merge main to features/FileScopedNamespaces

…ileScopedNamespaces

Merge main to features/FileScopedNamespaces

…nterpolated-string

Merge main to features/interpolated-string

* upstream/main: (75 commits)
  Split BoundInterpolatedString into BoundInterpolatedString and BoundUnconvertedInterpolatedString (dotnet#52061)
  Combine VB comparers into one, and combine VB and C# comparers together (dotnet#51834)
  Use OptimizedVSCompletionList in LSP scenarios.
  F5 Hot Reload (dotnet#52101)
  Fix typescript shim
  Add tests for lazy syntax trees coming from the GeneratorDriver
  React to code review feedback.
  Simplify the lazy-initalization pattern used in GetRoot
  Remove an unnecessary override. (dotnet#52140)
  Update issue number (dotnet#52130)
  Enable CodeActions support for XAML using its own provider and CodeActionCache. The handlers are actually shared with Roslyn as is. (dotnet#52129)
  Add RestrictedIVT to dotnet watch to Features (dotnet#52087)
  Don't try to highlight operators (dotnet#52041)
  Use `null` instead of empty signature helps in LSP
  Use member type for relational pattern even in error cases (dotnet#51950)
  Update src/VisualStudio/Xaml/Impl/Implementation/LanguageServer/Extensions/SymbolExtensions.cs
  Use new QuickInfoUtilities helper
  Rebuild API shape (dotnet#52079)
  Added position parameter name
  Updated XAML QuickInfo to show more info like C# by using ISymbolDisplayService and adding more documentation parts.
  ...

merge main

…nterpolated-string

Merge main to features/interpolated-string

…ileScopedNamespaces

Merge main to features/FileScopedNamespaces

…ileScopedNamespaces

Merge main to features/FileScopedNamespaces

…nterpolated-string

Merge main to features/interpolated-string

…ileScopedNamespaces

Merge main to features/FileScopedNamespaces

…nterpolated-string

Merge main to features/interpolated-string

…nterpolated-string

Merge main to features/interpolated-string

Switch progression search over to navto search by default.

Add records support to XmlDocCommentCompletion and ChangeSignature

[main] Update dependencies from dotnet/roslyn

See also microsoft/vs-threading#556

…tnet#54726)

* Prefer Concat on interpolated strings with 4 or less string parts

Fixes dotnet#54702. This does not implement any changes to prefer concat for ReadOnlySpan<char>: doing so will require a deeper change of the local rewriter's handling of string concatenation that we can revisit at a later date if we so choose.

Enable CA2012 (Use ValueTasks correctly)

…#54790)

* Simplify condition that must always be true

* Name parameter more clearly

* Make private and name properly

…4797)

* Reduce allocations in CSharp command line parsing

Context dotnet#53570

The C# parser is used by the project system in scenarios like solution
open. That means the allocations in command line parsing can contribute
significantly to Visual Studio performance. This PR reduces the
allocations significantly.

Note: in the below explanations when I refer to the "99% case" I am
referring to how command lines are structured when created by
MSBuild based builds. That is the **overwhelming** case for the compiler
and is advantageous because it normalizes many items like lower casing
all option names, having one reference per option, etc ...  The remaining
1% are hand authored build files and these should not impact Visual
Studio scenarios.

The first fix is to simply avoid iterators in the parse hot paths. Most
of the iterators in the parser return a single element in the 99% case
hence the iterator is wasted allocations. These were switched to take
pooled builder arguments.

The next, and more siginificant fix, is to use `ReadOnlyMemory<char>`
instead of `string` on our hot parsing paths. This allows us to parse
the command line arguments without actually allocating memory for the
values until actually needed by lower level APIs. This allowed for APIs
like `RemoveQuotesAndSlashes` to become allocation free in the 99% case
(it's just a slicing operation now, not a string allocation).

The hot paths in our parsing were updated to employ these techniques.

The one downside of the change is that I had to touch virtually every
`case "someOption"` where the option value was used. The value is now
held in a `ReadOnlyMemory<char>` until it's actually needed as a
`string`. Hence every one of these cases either needed to use the new
`ReadOnlyMemory<char>` APIs or force the allocation of the `string`.
That made the change longer than I would've liked but it's also fairly
mechanical.

To test out the changes I created a benchmark which parsed a couple of
command lines:

- Command line for building Microsoft.CodeAnalysis.CSharp
- Command line for a simple razor app

The results are below and represent a significant win in both
allocations and in simple performance. There are a few more places we
could get some wins but getting into the realm of diminishing returns at
this point.

Before

|                          Method |       Mean |    Error |   StdDev |    Gen 0 |    Gen 1 | Gen 2 | Allocated |
|-------------------------------- |-----------:|---------:|---------:|---------:|---------:|------:|----------:|
|  ParseCSharpCompilerCommandLine | 1,101.9 us | 16.05 us | 14.23 us | 242.1875 |  80.0781 |     - |    876 KB |
| ParseCSharpCompilerResponseFile | 1,916.7 us | 18.26 us | 14.26 us | 353.5156 | 175.7813 |     - |  2,082 KB |
|   ParseRazorCompilerCommandLine |   467.3 us |  2.27 us |  2.02 us | 350.5859 |  53.7109 |     - |    571 KB |
|  ParseRazorCompilerResponseFile |   850.6 us |  8.09 us |  7.17 us | 327.1484 | 102.5391 |     - |    953 KB |


After

|                          Method |       Mean |    Error |   StdDev |    Gen 0 |   Gen 1 | Gen 2 | Allocated |
|-------------------------------- |-----------:|---------:|---------:|---------:|--------:|------:|----------:|
|  ParseCSharpCompilerCommandLine |   771.7 us | 15.09 us | 19.62 us | 109.3750 | 20.5078 |     - |    200 KB |
| ParseCSharpCompilerResponseFile | 2,094.4 us | 20.04 us | 18.74 us | 105.4688 | 39.0625 |     - |    551 KB |
|   ParseRazorCompilerCommandLine |   249.5 us |  2.49 us |  2.33 us |  77.6367 | 14.6484 |     - |    136 KB |
|  ParseRazorCompilerResponseFile |   710.1 us |  5.97 us |  5.29 us |  88.8672 | 24.4141 |     - |    251 KB |

closses dotnet#53570

* Progress

* Response file parsing

* Fix build error

* PR feedback

* Linux test failure

* Fix test crash

* PR feedback

* Parse response file wins

* Update src/Compilers/Core/Portable/CommandLine/CommandLineParser.cs

Co-authored-by: Fred Silberberg <fred@silberberg.xyz>

* Fixed build correctness issue

Co-authored-by: Fred Silberberg <fred@silberberg.xyz>

…54320)