This change covers several pieces of work on shared extension methods:
1. Augment and document `AsSpan()`, `AsSpanOrDefault()`, `AsMemory()`,
and `AsMemoryOrDefault()` extension methods targeting string.
2. Augment and document `Contains()`, `IndexOf()`, `StartsWith()`, and
`EndsWith()` extension methods targeting string.
3. Add `AsSpan()` and `AsMemory()` extensions methods targeting array
and Razor's polyfill `Index` and `Range` types.
It's probably easiest to go through this commit-by-commit.
The main fix here is the `IndexOutOfRangeException` in the
`FilePathNormalizer`. The problem occurs when the array rented from the
pool already contains a `\` or `/` immediately after the span that we
care about. It was possible for
`FilePathNormalizer.NormalizeAndDedupeSlashes(...)` to read past the end
of the span, and if it found a `\` or `/` there, it would cause the
incorrect length to be used later, causing an
`IndexOutOfRangeException`. The reason the failure was intermittent is
because it's dependent on the contents of the array pool.
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
Part of https://github.com/dotnet/razor/issues/9519 and
https://github.com/dotnet/razor/issues/10603
This was fairly straight forward too, though adding MVC files to the mix
found a bug in our test data, which is kind of humorous.
I decided not to copy all of the semantic tokens tests we have, but
rather just create something reasonably all-encompassing. The core
engine is shared so both sets of tests exercise it anyway.
This was simply a mistake on my part. We should not assume that code is unreachable when it is reached because an OperationCanceledException is caught.
The ProcessWorkAndRestart test was throwing an exception and swallowing it because a document was added to a project when the document's file path was outside of the project's.
It turns out that an old bug and some recent changes were causing
`MS.VS.LanguageService.Razor.Test` unit tests to fail intermittently.
1. I made a mistake when porting `AsyncBatchingWorkQueue` from Roslyn
that would cause an exception to be thrown if an
`OperationCanceledException` was thrown during batch processing.
2. `RazorActivityLog` would switch to the main thread when processing a
batch of messages. However, this is unnecessary, since `IVsActivityLog`
is supposed to a be a thread-safe VS service.
3. `RazorActivityLog` didn't check its cancellation token while
processing a batch of messages. This is problematic because it would
continue logging messages after `RazorActivityLog` was disposed.
4. The `IAsyncServiceProvider` mock passed to `RazorActivityLog` didn't
implement `IAsyncServiceProvider3`, which is super important. If that
interface isn't implemented, Visual Studio's `GetServiceAsync<TService,
TInterface>()` extension method will end up calling
`ThreadHelper.JoinableTaskFactory.SwitchToMainThreadAsync()`, which will
fail in tests.
Together, these issues could cause the test process or AppDomain to
crash when the `LspEditorFeatureDetectorTest` tests were run. Since
these unit tests run in parallel, the end result would be strange
exceptions in other tests due to the test environment being torn down.
Andrew Hall (METAL)
Dustin Campbell
Jan Jones
David Wengier
dotnet bot