Merge pull request #30758 from jasonmalinowski/enable-incremental-updates-of-the-dependency-graph-for-dev15.9.x

Enable incremental updates of the dependency graph

We support dangling project references in the workspace API,
and the ProjectDependencyGraph is only supposed to return references
that exist within the project. Therefore, if we add a project, we have
to check to make sure we didn't have a dangling reference becoming a
real reference, and give inconsistent results.

I expect this to be a rare situation in reality so don't want to spend
a lot of time optimizing for it, but if it happens this will keep
everything in sync.

Some of these are particularly hard; we have a lazy data structure that
has "I don't know" as something the algorithm needs to deal with.
Unfortunately trying to test through the public Solution APIs often
doesn't work because the Solution code accidentally asks the dependency
graph for things which then invalidates the "I don't know" by causing
it to compute things.

It's unclear to me why we have another implementation of computing
transitive project references; we'll just call our existing
implementation.

Any time we made a change to the dependency structure of a solution,
we threw away the dependency graph entirely and recomputed it. This
was pretty wasteful, since we'd promptly recompute parts of it as
a part of the workspace solution forking. The allocations were quite
high, often to recompute the (almost) exact same immutable data as
before.

This adds the abilty to take an existing ProjectDependencyGraph and
update it to produce a new graph with project references added, which
reuses whatever data was easily available.

We already have an API for adding multiple project references; let's
just use that at the public entrypoints than trying to maintain
near-duplicate code.

This will make it easier to assert intermediate states.

By not using the map, we can easily have helpers that can be called
by additional tests directly.

The code in CreateSolutionFromReferenceMap tried very hard to support
the ability that if you had the same project name with different
references, that we should merge all the different references together
For example, "A:B A:C" should be equivalent to "A:B,C". But if you
tried this, it would have crashed anyways becuase we'd see a duplicate
project name. Since it doesn't work, no reason to keep it around.

These methods do not return topologically sorted results; not only
is that not something that really makes sense, but they return
IImmutableSets anyways so they have no way to guarantee ordering at all.

Change analyzer executor to do an intersection with the given span 

For cases where the requested span is (x, x), try using span
intersection rather than contains.

That should cover all the cases for requesting the diagnostics
at caret

Fixes #27703

Revert "Fix #30091 throwing exceptions"

This reverts commit b3ac2a6f.

The general pattern when registering code fixes seems to be
either passing diagnostics[0] or diagnostics.First().

RemoveUnusedVariable seems to be the only outlier in this case,
doing .Single().

Having multiple diagnostics on a span would cause the code fix
to throw an exception

Bypass auto-pretty-listing of large VB code

Do not use SQLITE_OPEN_SHAREDCACHE

Fix issue when adding/removing event handlers again and again

There's a variety of cases in the compiler where we need to store an
expression into a temporary variable, e.g. to sequence side effects
in the right order. This code was not adjusted to deal with in
parameters, so it exhibited various pathologies.

The first case is the simplest -- sometimes when using the "explicit in"
modifier on an argument, the temp creation routine would simply crash.

The other cases are more subtle and mostly have to do with whether or
not the temp is created as a ref local or regular local. This is
specific to the "implicit in", where the "in" keyword is not mentioned
on the argument. In this case, the semantics for the call should be that
the argument is passed by-ref without storing to a copy unless
absolutely necessary. Absolutely necessary in this case is defined as 1)
the argument is an rvalue or 2) the argument requires a conversion to
the parameter type.

A lot of this knowledge was already present in CodeGen, but not available
in lowering, so I've pulled out the HasHome helper to Binding, as I felt that
was the best place for the common code.

Fixes #29371

This flag can only be used when the application manages concurrency for
database write operations to ensure no more than one connection is
writing data at any given point. Roslyn only provides the weaker
guarantee that each connection is only used from one thread at a time,
but may be used for reading or writing.

Fixes #29599

An issue has existing for a long while that is caused by Code Model. The repro looks
something like this:

1. Double-click a Button to generate a Click event handler.
2. Undo
3. Double-click the Button again.

The XAML designer team is now running into this as well, so a fix is definitely overdue.

The issue here has to do with the cache of COM objects that Code Model maintains. Essentially,
when a new `CodeElement` is added to the cache, we need to first check to see if there's an
element already in the cache with the same key. If there, is, we now remove the original element
from the cache before adding the new one. If somebody still has a reference to the original
`CodeElement`, it'll still continue to function since it points to a valid syntax node key.

The formatter produces large and complicated diffs for content generated
for large VB forms, resulting in long delays when working with the
designer. This change bypasses pretty listing for cases where the dirty
span exceeds a "large span theshold" of 7000 lines.

Fixes https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems/edit/659925

Merge dev15.9-preview2 to dev15.9.x

Merge dev15.9-preview1 to dev15.9-preview2

Merge dev15.9-preview2 to dev15.9.x

follow up fix for https://github.com/dotnet/roslyn/pull/29066