Sometimes other features need to light up if there's a C# or VB project
present. A good example is some of the test tooling: they don't want to
load their components with Roslyn unless somebody is also using the test
tooling, but you don't want to accidentally load Roslyn if somebody is
using the test tooling only for C++.

Fixes https://devdiv.visualstudio.com/DevDiv/_queries/edit/844761/

we can lose OOP connection due to many reason such as user explicitly killing OOP process.

we have made that not to kill VS but this one place it looks like it can still crash VS.

this could be due to StreamJsonRpc now throwing ConnectionLostException rather than general RemoteInvocationException it used to throw for everything.

when we lost exception we do the normal pattern. showing info bar asking users to restart VS and send NFW but move on.

When we're inferring around error types, we won't add ?s for now because
they're more likely to be classes than structs, and we don't know yet
exactly where the resulting syntax will get put.

https://github.com/dotnet/roslyn/issues/37852 will track a fancier fix
to this.

If we have inferred the thing to the left of a ?? is a reference type,
we can annotate it; we didn't update that yet in the type inferrer
though until we had the ability to properly remove the ? if the
user wasn't in the right context. The parent commit of this commit fixes
that so we can fix this now.

When we're generating code, we always will annotate any reference
types that are known to be nullable. But we might be sticking that
resulting syntax into a different file where the context disables
annotations; now we will remove those ? tokens to keep code building.

It's possible we could do fancier things too where we instead realize
the user wants to surround the code with #nullable enable, but for now
we'll take this simple approach.

Fixes https://github.com/dotnet/roslyn/issues/37178

At this point, the flighting controls we have aren't really useful
anymore: we want this on for everybody unless the opt out, and that
opt-out would be specific to certain users that are running into issues
with the new system to keep them unblocked. I'm keeping this a per-
machine setting (that doesn't roam) because it's really repo or VS
version specific.

This code as was written was a bit shaky. The Workspace constructor
would ask for the workspace option service, and this would cause us
(while creating the service) to call RegisterDocumentOptionsProvider.
If that results in one of the options providers also asking for options,
we recursively request the option service while still trying to
construct it.

The fix is just to move the registration to the workspace constructor
itself which removes the circularity and matches the pattern used
everywhere else.

Most of the type inferrer tests test both overloads of the
type inferrence service -- the one that takes a span and one that
takes a position. Both (by default) were tested, but it's impossible
without actually debugging a test to know which one failed. I had a
particular irritating case where I made a behavior change and had to
update a bunch of tests with new baselines, but since the behavior
also split between both APIs it was confusing to figure out what was
going on.

When generating code from the navigation bar, we should remove
inaccessible attributes, since there's no value in spitting code that
won't build.

Fixes https://github.com/dotnet/roslyn/issues/37621 although perhaps not
in the ideal way. We may also want to generally drop all nullable
attributes when generating VB code, but that's being tracked by
https://github.com/dotnet/roslyn/issues/30327 as there's some design
questions still out.

Fixes #37224
Fixes #37268
Fixes #37361

This should fix the performance issues reported in VS feedback tickets [#672009](https://developercommunity.visualstudio.com/content/problem/672009/live-analysis-eats-up-memory-resulting-in-vs-crash.html) and [#672909](https://developercommunity.visualstudio.com/content/problem/672909/live-code-analysis-extremely-slow-and-vs-2019-cras.html)

There was a previous parsing change (#32999) which modified namespace
parsing to allow modifiers and attributes on namespaces, to improve
error recovery.

This PR contained a bug because it didn't move the incremental parsing
check to before parsing attributes and modifiers, which should now
be included in incremental parsing to prevent changes from being dropped

Fixes #37665, #37664, #37663

Co-Authored-By: NMarius Ungureanu <teromario@yahoo.com>

Co-Authored-By: NMarius Ungureanu <teromario@yahoo.com>

https://github.com/dotnet/roslyn/issues/18779

The type inferrer does method type inferrence if we know what the
return type of the method should be. This triggered if the method was
handled an argument which it could then chase up and find the
InvocationExpressionSyntax. Unfortunately if you are inferring and
don't have an argument you still want to be able to infer the type
of the argument if there was one there, but there's no ArgumentSyntax
to work from. Thus, it's easier to just directly pass the
InvocationExpressionSyntax and avoid the tree walk; looking through
the callers of InferTypeInArgument there's only one place where
it could potentially find an InvocationExpressionSyntax, and that one
place is the place I updated the call site on.

There are a few parts to this change:

1. Ensure that MSB3270 and MSB3277 warnings are promoted to errors in CI
and hence block merging.
1. Move our DiaSymReader.Native logic into a separate targets file.
This resource cannot be consumed with a simple package reference but
rather requires a package reference and custom logic to pull out the
contained binaries. This logic used to be spread through our build. Now
it's in a single place.
1. Remove the x86 bootstrapping logic. This was testing a pretty obscure
scenario and the cost of maintaining that logic is siginificant at this
point. Can bring back if we ever find a bug in this area.

The root cause of the MSB3270 warnings is a subtle change in the SDK. It
now passes the runtime graph to NuGet for native assets. In the case of
DiaSymReader.Native there are runtime specific assets hence the SDK /
NuGet had to pick one for framework projects. This eventually lead to
`PlatformTarget` being set to x86 where it shoud have been AnyCPU.

Part of the change includes adding `ExcludeAssets=all` to the package
reference which means they no longer figure into this logic and hence
the binaries are marked as AnyCPU.

This regression in behavior is being tracked by
https://github.com/dotnet/sdk/issues/3495