…et#81420)

Test plan: dotnet#81207

Everything under section [Existing `unsafe`
rules](https://github.com/dotnet/csharplang/blob/main/proposals/unsafe-evolution.md#existing-unsafe-rules)
of the speclet should be now handled.

Test plan: dotnet#81207

Inspired by RefSafetyRules attribute.

Relevant speclet section:
https://github.com/dotnet/csharplang/blob/main/proposals/unsafe-evolution.md#metadata

…ods and properties (dotnet#81581)

Test plan: dotnet#81207

More member kinds (besides methods and properties; and also some other
types of methods, like synthesized methods) will be handled in a follow
up (once this proof of concept is approved). OHI is also not handled in
this PR.

…otnet#81698)

Test plan: dotnet#81207

Follow up on dotnet#81581 (i.e., still
only for methods and properties).
1. Checking lang version.
2. Improving some tests.

Test plan: dotnet#81207

Follow up on dotnet#81581 (i.e., still
only for methods and properties).

Implements this speclet section:
https://github.com/dotnet/csharplang/blob/80f7e032a3131f1d9c2c6822b8a03cf56eeda005/proposals/unsafe-evolution.md#compat-mode

Test plan: dotnet#81207

Only one trivial conflict due to a variable rename from
dotnet#81651 (in PEMethodSymbol.cs on
line 1042).
Plus need to fixup the feature flag otherwise it fails on assert as an
unknown feature flag due to dotnet#81591
- commit
dotnet@0ae3719.

Test plan: dotnet#81207

Test plan: dotnet#81207

Follow up on dotnet#81581 (i.e., still
only for methods and properties).

Implements this speclet section:
https://github.com/dotnet/csharplang/blob/d4a7252e082927c9e6d6f1386d0bb46fa690db8b/proposals/unsafe-evolution.md#extern

No conflicts.
Test plan: dotnet#81207

Test plan: dotnet#81207
OHI not handled as part of this PR.
Delegates handled according to this open question:
https://github.com/dotnet/csharplang/blob/79da45137622071d3c80ebe0a1296387af67afb9/proposals/unsafe-evolution.md#delegate-type-unsafety
(i.e., it's not possible to mark delegates as caller-unsafe - I'd expect
this to be approved and even if not, it seems like a good starting point
- see also comments by jkotas under
dotnet/csharplang#9831).

Test plan: dotnet#81207
Implements this part of the speclet: [Overriding, inheritance, and
implementation](https://github.com/dotnet/csharplang/blob/61f06216967ed264a8f83c71bff482f3eb6ac113/proposals/unsafe-evolution.md#overriding-inheritance-and-implementation)

Test plan: dotnet#81207
All conflicts resolved in the last commit only.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: dibarbet <5749229+dibarbet@users.noreply.github.com>
Co-authored-by: Cyrus Najmabadi <cyrus.najmabadi@gmail.com>
Co-authored-by: David Barbet <dabarbet@microsoft.com>
Co-authored-by: Joseph Musser <me@jnm2.com>
Co-authored-by: Joey Robichaud <jorobich@microsoft.com>
Co-authored-by: Fred Silberberg <frsilb@microsoft.com>
Co-authored-by: dotnet bot <dotnet-bot@dotnetfoundation.org>
Co-authored-by: dotnet-policy-service[bot] <123482357+dotnet-policy-service[bot]@users.noreply.github.com>
Co-authored-by: CyrusNajmabadi <4564579+CyrusNajmabadi@users.noreply.github.com>
Co-authored-by: Jason Malinowski <jason.malinowski@microsoft.com>
Co-authored-by: DoctorKrolic <mapmyp03@gmail.com>
Co-authored-by: DoctorKrolic <70431552+DoctorKrolic@users.noreply.github.com>
Co-authored-by: Glen <glen.84@gmail.com>
Co-authored-by: David McFarland <corngood@gmail.com>
Co-authored-by: AlekseyTs <AlekseyTs@users.noreply.github.com>
Co-authored-by: Phil Allen <phillipa@microsoft.com>
Co-authored-by: Thomas Shephard <thomas@thomas-shephard.com>
Co-authored-by: Cyrus Najmabadi <cyrusn@microsoft.com>
Co-authored-by: David Wengier <david.wengier@microsoft.com>
Co-authored-by: Julien Couvreur <12466233+jcouv@users.noreply.github.com>
Co-authored-by: Tomáš Matoušek <tmat@users.noreply.github.com>
Co-authored-by: Ankita Khera <40616383+akhera99@users.noreply.github.com>
Co-authored-by: Todd Grunke <toddgrun@microsoft.com>
Co-authored-by: Rikki Gibson <rigibson@microsoft.com>
Co-authored-by: David Barbet <dibarbet@gmail.com>
Co-authored-by: Jason Malinowski <jason@jason-m.com>
Co-authored-by: JoeRobich <611219+JoeRobich@users.noreply.github.com>
Co-authored-by: Joey Robichaud <joseph.robichaud@microsoft.com>
Co-authored-by: ratijas <ratijas.tkachenko@gmail.com>
Co-authored-by: cui <cuiweixie@gmail.com>
Co-authored-by: Kirill Osenkov <KirillOsenkov@users.noreply.github.com>
Co-authored-by: Jeremy Koritzinsky <jkoritzinsky@gmail.com>

Co-authored-by: dibarbet <5749229+dibarbet@users.noreply.github.com>

Co-authored-by: dibarbet <5749229+dibarbet@users.noreply.github.com>

…et#82419)

If you ended up with a project that had a reference to itself, removing
that project could result in trying to convert that reference to
another project, if another project also had the same output path.
This would result in us trying to dispose of a reference that had
already been disposed.

This was found as a part of an investigation of
https://developercommunity.visualstudio.com/t/Project-system-data-flow-Workspace-upda/10772773
but I don't believe this fixes that issue.

This adds a test which can try to help catch bugs like
https://developercommunity.visualstudio.com/t/Project-system-data-flow-Workspace-upda/10772773

…dotnet#82435)

Fixes issue found by @davidwengier where we can't use FatalError in
clasp (used by Razor/Webtools who do not have that type).

Also fixes issue where if the server encountered a queue error in VS, it
could not be restarted as restart would throw.

This pull request updates the following dependencies

[marker]: <> (Begin:c9d72f90-91b9-4504-a914-d7da223eec78)
## From https://github.com/dotnet/roslyn
- **Subscription**:
[c9d72f90-91b9-4504-a914-d7da223eec78](https://maestro.dot.net/subscriptions?search=c9d72f90-91b9-4504-a914-d7da223eec78)
- **Build**:
[20260220.3](https://dev.azure.com/dnceng/internal/_build/results?buildId=2908966)
([302724](https://maestro.dot.net/channel/548/github:dotnet:roslyn/build/302724))
- **Date Produced**: February 20, 2026 7:07:22 PM UTC
- **Commit**:
[31befaa](dotnet@31befaa)
- **Branch**: [main](https://github.com/dotnet/roslyn/tree/main)

[DependencyUpdate]: <> (Begin)

- **Dependency Updates**:
  - From [5.3.0-2.25625.1 to 5.5.0-2.26120.3][9]
     - Microsoft.CodeAnalysis
     - Microsoft.CodeAnalysis.Analyzers
     - Microsoft.CodeAnalysis.AnalyzerUtilities
     - Microsoft.Net.Compilers.Toolset
  - From [5.4.0-2.26062.101 to 5.5.0-2.26120.3][10]
     - Roslyn.Diagnostics.Analyzers

[9]: dotnet/roslyn@5dd606b...31befaa
[10]: dotnet/roslyn@7b9ad20...31befaa

[DependencyUpdate]: <> (End)


[marker]: <> (End:c9d72f90-91b9-4504-a914-d7da223eec78)

---------

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Ankita Khera <40616383+akhera99@users.noreply.github.com>

Fixes dotnet#82474.

…net#82537)

Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2745956

…2459)

Followup to dotnet#82457

## Summary (part 1)

Changes `WordSimilarityChecker.GetThreshold` from `length <= 4 ? 1 : 2`
to `length <= 5 ? 1 : 2`, so that 5-character patterns now require edit
distance ≤ 1 instead of ≤ 2 for a fuzzy match.

## Motivation

The original threshold tiers (`≤4 → 1`, `≥5 → 2`) were chosen by me
10-15 years ago based on gut feeling and a small amount of manual
testing. They work well in practice, but the jump to k=2 at length 5
creates a blind spot in the bigram pre-filter introduced in dotnet#82457: the
q-gram count lemma gives `min_shared = 5 - 1 - 2*2 = 0`, meaning the
bigram filter *cannot eliminate any candidates* for 5-character
patterns.

The industry standard for this exact problem is Elasticsearch/Lucene's
[`fuzziness:
AUTO`](https://www.elastic.co/guide/en/elasticsearch/reference/current/common-options.html#fuzziness)
setting, which uses:

| Pattern length | Max edit distance |
|---|---|
| 1–2 | 0 (no fuzzy matching) |
| 3–5 | 1 |
| 6+ | 2 |

This is grounded in [Damerau's
finding](https://en.wikipedia.org/wiki/Damerau%E2%80%93Levenshtein_distance)
that approximately 80% of human misspellings are edit distance 1, and
that allowing 2 edits on short strings produces too many false positives
(e.g., two edits can transform a 5-character word into something
completely unrelated).

## What changes

Only the length-5 case is affected:

| Pattern length | Before (k) | After (k) |
|---|---|---|
| 1–2 | N/A (`MinFuzzyLength = 3`) | N/A (unchanged) |
| 3–4 | 1 | 1 (unchanged) |
| **5** | **2** | **1** |
| 6+ | 2 | 2 (unchanged) |

`MinFuzzyLength = 3` is deliberately kept — below that length, fuzzy
matching produces too many spurious hits regardless of threshold.

## Effect on pre-filter

With the new threshold, the bigram pre-filter becomes effective at
length 5. The `min_shared` column shows the minimum number of pattern
bigrams that must appear in the candidate for the q-gram count lemma to
permit a match (`|pattern| - 1 - 2k`). Higher values mean stronger
filtering:

| Pattern length | Before: k, min_shared | After: k, min_shared |
Filtering strength |
|---|---|---|---|
| 3 | k=1, 0 | k=1, 0 | None (always passes) |
| 4 | k=1, 1 (of 3 bigrams) | k=1, 1 (of 3 bigrams) | Weak |
| **5** | **k=2, 0** | **k=1, 2 (of 4 bigrams)** | **None -> Moderate**
|
| 6 | k=2, 1 (of 5 bigrams) | k=2, 1 (of 5 bigrams) | Weak |
| 7 | k=2, 2 (of 6 bigrams) | k=2, 2 (of 6 bigrams) | Moderate |
| 8 | k=2, 3 (of 7 bigrams) | k=2, 3 (of 7 bigrams) | Strong |
| 10+ | k=2, increasingly strong | k=2, increasingly strong | Very
strong |

## Risk

Exceptionally low. This is a one-line behavioral change that tightens a
fuzzy match heuristic for a single pattern length. Fuzzy matching is
already a best-effort "did you mean?" feature — slightly fewer fuzzy
matches at length 5 is the expected and desired outcome.

## Summary (part 2)

The `allowFuzzyMatching` boolean was threaded through 7 locations in the
pattern matching pipeline, yet only 2 of 6 callers ever enabled it.
`ContainerPatternMatcher` hardcoded it to `false` everywhere. The
interleaving of fuzzy and non-fuzzy logic made the code harder to follow
than necessary.

## Design

Each matcher now has a single responsibility:

- **`SimplePatternMatcher`**: exact, prefix, camelCase, substring
(non-fuzzy)
- **`FuzzyPatternMatcher`** (new): edit-distance only via
`WordSimilarityChecker`
- **`CompoundPatternMatcher`** (new): composes sub-matchers, tries each
in order, short-circuits on first match
- **`ContainerPatternMatcher`**: unchanged

A new `[Flags] enum PatternMatcherKind { None, Standard, Fuzzy }`
controls which strategies to use. The factory returns the appropriate
matcher (or compound) based on the flags. Callers just pass the enum:

```csharp
using var matcher = PatternMatcher.CreatePatternMatcher(
    pattern, includeMatchedSpans: true, PatternMatcherKind.Standard | PatternMatcherKind.Fuzzy);
```

`NavigateToSearchIndex.CouldContainNavigateToMatch` now returns
`PatternMatcherKind` (instead of `bool` + two out-params), which flows
directly into the factory.

The base `PatternMatcher.AddMatches` is now non-abstract and handles
`SkipMatch` centrally; subclasses implement `AddMatchesWorker`.

---------

Co-authored-by: Cyrus Najmabadi <Cyrus Najmabadi>
Co-authored-by: Cursor <cursoragent@cursor.com>

Test plan: dotnet#81207
Speclet:
https://github.com/dotnet/csharplang/blob/main/proposals/unsafe-evolution.md
Proposal issue: dotnet/csharplang#9704

Follows up on a comment I missed from @jjonescz to consolidate .globalconfigs.