made diagnostic engine to verify span given to diagnostic from analyzers. and added explicit check in tagger for out of range

Fix crash in VB type inferrer

Accessibility for Inline Rename in the Editor

This reverts commit 2fba37a6.

By design, when data flow analyzes local functions it does so devoid of
surrounding context and records possibly unassigned variables rather
than reporting a diagnostic. Thus, all captured variables are expected
to be marked unassigned during data flow analysis without reporting a
diagnostic.

However, reporting a diagnostic is not the only side effect of running
data flow analysis. By calling virtual methods data flow analysis
informs derived types of unassigned variables. While the diagnostic is
suppressed and recorded, currently the virtual method is still called.
This has negative consequences for region analysis, which considers
these calls as indications of variables flowing out of the given
region, which may not be the case for local functions.

This PR changes data flow analysis to only call the ReportUnassigned
virtual method if not inside a local function, excluding local functions
from all unassignment reporting.

Fixes #17165, #18347

Fixes
https://devdiv.visualstudio.com/DevDiv/_workitems?id=391624&_a=edit

- Inline Rename fields now consist of a themeable/customizable
background, foreground, and border. The border is used in High Contrast.
- Resolved and Unresolved conflict borders can now be themed &
customized.
- Resolved and Unresolved conflict borders now have different dash
styles so they are distinct from each other and regular Inline Rename
fields. The Dashboard shows a key indicating which type of conflict
corresponds to which border dash style.

Skip repl VSI tests

Log telemetry if we see ITextBufferEdit.Apply() throwing exceptions

Failure tracked by https://github.com/dotnet/roslyn/issues/20219

Looks like there is still fall out from the licensing issue.  VS integration tests still failing
at 100% due to a timeout issue.  Change them to not run by default while we look into this.

Can still be run manually for testing with

test vsintegration please

Move language settings after SDK import

The new SDK unconditionally sets a number of MSBulid properties
including many that we depend on in Roslyn.  This is a break from the
old MSBuild behavior which respected initial values.

https://github.com/dotnet/sdk/issues/752

The behavior in 2.0 is changing to go back to the old model of
respecting initial values.  Roslyn though continues to often use the SDK
installed with Visual Studio.  That can be a variety of values from 2.0
prebuilds, to various drops of 1.0.

As a result the success / failure of our build can depend a lot on which
version of VS is installed and by consequence which new SDK comes with
it.  Subtle differences in the SDK can change the values we end up
compiling with in our project.  We've been guarding against this
by directly re-setting values we knew to be overidden in some version
of the SDK.

Now though I'm worried this isn't an adequete solution for the following
reasons.

- Just this week I got new warnings in the build by using a new VS
- The Microbuild lab is aggressively grabbing new builds of VS which
means the VS SDK is also potentially changing.

After some thought I decided to simply move all of our langauge specific
settings after we import the core targets.  Given that we
unconditionally set the values it becomes irrelevant what the SDK does
or does not respect.

Be resilient to running with System.IEquatable can not be found.
Fixes #20158

Fix race with boosting OOP priority.  Also, ensure FindRef calls are boosted.

Force load projects that failed design time builds, not ones that opt out of LSL

Remove strong reference to AnalyzerOptions in the analyzer manager ex…

Track down NuGet cache corruption

Revert "allow waiters to be consumed from internal VS tests"

Refactor tests

Add a unit test to ensure that analyzer execution does not leak solution instances from preview workspace.

This change should help us pin down why we are seeing NuGet cache
corruption issues in our Jenkins job.  It adds a check to three places
in our script:

- Start
- Post restore
- End

Depending on when this check fails it should give us a better picture of
where the corruption is occuring.

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

Hack around PublicAPI item group support in the new project system

Move Roslyn assemblies to consume newer OptimizationData

This is a workaround for dotnet/project-system#2160 where
AdditionalFileItemNames isn't quite behaving correctly with the IDE.
This can be reverted once that bug is fixed.

This reverts commit 8a1ca479 and moves
publish earlier in the build pipeline (before signing) to prevent
published binaries from overwriting already built and signed binaries.

Fixes #20065

This should likely fix an RPS regression (VSO 440011) related to additional jitting of Roslyn assemblies.

The solution build manager will handle the opted out ones, but not the failed design time build ones.

Fixes #19407.