Update feature branch #10652

# Conflicts: # src/Razor/src/Microsoft.AspNetCore.Razor.LanguageServer/Formatting/CSharpFormatter.cs # src/Razor/test/Microsoft.AspNetCore.Razor.LanguageServer.Test/Formatting/FormattingLanguageServerClient.cs # src/Razor/test/Microsoft.AspNetCore.Razor.LanguageServer.Test/Formatting/FormattingTestBase.cs

Since we were talking in the working group meeting, thought I'd give it a go and see if it passes

# Conflicts: # src/Razor/src/Microsoft.AspNetCore.Razor.LanguageServer/Formatting/CSharpFormatter.cs # src/Razor/src/Microsoft.AspNetCore.Razor.LanguageServer/Formatting/CSharpOnTypeFormattingPass.cs # src/Razor/test/Microsoft.AspNetCore.Razor.LanguageServer.Test/Formatting/FormattingLanguageServerClient.cs # src/Razor/test/Microsoft.AspNetCore.Razor.LanguageServer.Test/Formatting/TestRazorFormattingService.cs

…s) (#6166) Requires: - [x] dotnet/roslyn#59679

…uctor

* Removing unnecessary Razor Legacy Editor feature flag AFAIK it was introduced for new LSP editor rollout several years ago before we had Tools/Options/HTML Editor/Advanced/Use legacy Razor Editor option. Now that rollout is over, and there is a public non-preview mechanism for users to switch to the old editor if needed, the feature flag is no longer necessary and creates confusion (and extra code to test/maintain). * Fixing a unit test (test matrix) * Fixing spacing per CR suggestion Co-authored-by: David Wengier <[email protected]> --------- Co-authored-by: David Wengier <[email protected]>

This PR is a style-only clean up of our code actions handlers and related code. Definitely could have gone further (more collection pooling, returning concrete types etc.) but I wanted to try to have it serve as an indication for what we consider our current idiomatic coding style* and to avoid conflicts with the extract to component work. <sub>* Current style is subject to change at any time, and are not well documented. To quote a great Australian film, [it's just the vibe](https://www.youtube.com/watch?v=nMuh33BMZYY).</sub>

* Update dependencies from https://github.com/dotnet/arcade build 20240702.2 Microsoft.SourceBuild.Intermediate.arcade , Microsoft.DotNet.Arcade.Sdk From Version 8.0.0-beta.24352.1 -> To Version 9.0.0-beta.24352.2 * Install .NET 8 runtime * Update dependencies from https://github.com/dotnet/arcade build 20240702.2 Microsoft.SourceBuild.Intermediate.arcade , Microsoft.DotNet.Arcade.Sdk From Version 8.0.0-beta.24352.1 -> To Version 9.0.0-beta.24352.2 * Disable BuildWithNetFrameworkHostedCompiler --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Jan Jones <[email protected]>

* Manually validate if additional files and metadata references have actually changed * Short circuit metadata ref comparer * Add tests

We can avoid sifting through all tag helpers and performing string comparisons by storing tag helpers them in a dictionary keyed by assembly name.

Part of #9519 Finally some cohosting tests! Some people would say that I'm being lazy in adding tests for the simplest endpoint we have. Those people have a point. The test infra here almost entirely avoids ServiceHub, and certainly avoids the Roslyn solution sync mechanism, but it _does_ use our real services and service factories, including the OOP services' separate MEF composition, so the services themselves are partying on a real Roslyn (test) solution and are using real implementations of all of their dependencies. Things not covered by this test infra yet: * OOP initialization * Adding generated C# files to the Roslyn solution (IDynamicFile does this in real life) * Dealing with Html documents in any way Future PRs to add tests for more endpoints should add these as needed.

While self-hosting I noticed unified settings were no longer available and were defaulting back to the classic experience. Looks like they updated how some of the registration works and added a fix for f5 debugging them. Worked locally on my machine but I will not claim any expertise here.

This change introduces four sets of extension methods with overloads: - OrderAsArray(...) - OrderDescendingAsArray(...) - OrderByAsArray(...) - OrderByDescendingAsArray(...) Each of these operates on an `ImmutableArray<T>` and returns an `ImmutableArray<T>`.

### Summary of the changes - The constructors of MEF parts must be free threaded - Get `IVsTextManager4` on demand, rather than in the constructor of `RazorLSPTextViewConnectionListener` - This removes UI thread dependency, and allows Razor to be loaded asynchronously on solution restore, reducing UI delay on startup. Fixes: #10592

Cleaning up some places that are newing up Lists intead of using the object pool. I also moved a few things to ImmutableArray instead of List since they weren't mutated after initial collection

1. Don't sort if the array has zero or 1 element. 2. Don't sort if the array or the keys are already ordered. 3. Avoid creating an `IComparer<T>` until its time to actually sort Add tests for Comparison<T> overloads

This change adds `First()`, `FirstOrDefault()`, `Last()`, `LastOrDefault()`, Single()`, and `SingleOrDefault()` extension methods for `IReadOnlyList<T>` along with a comprehensive set of overloads. In addition, I've added an `AsEnumerable()` that returns a struct that wraps `IReadOnlyList<T>` with a struct enumerator. This makes it easy to foreach over an `IReadOnlyList<T>` without allocating.

…r<T>

…ding anything from service broker

I did a bad. Well a couple of bads. A few things this PR does/issues we (I 😛) had: * All of our OOP services are disposable, but the interfaces and type constraints didn't reflect that, so I missed disposing them in tests. This fixes that by disposing the services, but also: * We were using service factories to create our services, which meant some service broker types were involved that needed to be disposed. Now we create our services directly and no service broker types are needed * Logging in OOP uses a single TraceSource for all services, which is arguably dodgy but a limitation of our MEF based logger factory. In tests however, reusing the test output helper is a bad thing, so I've just removed the logging for tests for now.

* Fix NRE when invoking completion in empty document In empty document completion context will have RazorDocumentSyntax as Owner. RazorDoucmentSyntax has null as the parent, which makes sense. However compiler thinks we can't have a null here, while obviously we do. I'm adding a null check and a test for this case. We would probably further discuss the implications here. I tried to track down how we get null in a non-nullable field, but it's a bit confusing since the class gets generated. * Move RazorDocumentSyntax special case inside switch per CR suggestion * Fixing build

…#10618)

This change adds a new `GetPooledArraySpan(...)` extension method that returns a pooled array as a `Span<T>` with the expected length. This can help avoid bugs that can occur if a pooled array's `Length` is accidental used.

When reading RazorProjectInfo from a stream the array being used was a pooled array. The code was not correctly trimming that array for the deserializer which meant that unknown bytes were being attempted to be read and were likely wrong. This fixes the code to make sure and trim before deserializing and adds tests. Fixes AB#2137098

This change introduces four sets of extension methods with overloads: - OrderAsArray(...) - OrderDescendingAsArray(...) - OrderByAsArray(...) - OrderByDescendingAsArray(...) Each of these operates on an `ImmutableArray<T>` and returns an `ImmutableArray<T>`.

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.

IVsActivityLog is thread-safe so there's no need to switch to the main thread before using it.

Importantly, this includes an implementation of `IAsyncServiceProvider3`, which allows Visual Studios's `IAsyncServiceProvider` extension methods to avoid calling into `ThreadHelper`.

This change adds `First`, `FirstOrDefault`, `Last`, `LastOrDefault`, `Single`, `SingleOrDefault`, `Any` and `All` LINQ-style APIs to `PooledArrayBuilder<T>`.

@ToddGrun

…10602) This is some follow-up work after a discussion with @ToddGrun. Previously, @ToddGrun made [a change](#10537) to use pooled lists within the `DirectiveVisistors` used by `DefaultRazorTagHelperContextDiscoveryPhase`. However, looking at further traces, there is still a ton of CPU-bound work. Notably, there are loads of string comparisons that happen over and over to compare strings for assembly names. To address this, I've made the following changes: 1. Instead of using pooled lists, the `DirectiveVisitors` themselves are pooled and they own their data structures. 2. `TagHelperDirectiveVisitor` has been updated to store a `Dictionary<string, List<TagHelperDescriptor>>` rather than a flat `List<TagHelperDescriptor>`. This is used to index tag helpers by assembly name, which greatly reduces the number of string comparisons. The `List<TagHelperDescriptor>` held stored in the dictionary are pooled to avoid extra allocations of tag helpers per assembly.

- Add overloads for string.AsSpan() and string.AsMemory() that take Razor's Index and Range polyfill types. - Add overloads for string.AsSpanOrDefault() and string.AsMemoryOrDefault() that take start, start+length, and Razor Index and Range polyfill types. Note: If compiling for .NET, these forward to the relevant runtime methods.

Add overloads for string.Contains(), IndexOf(), StartsWith, and EndsWith() extensions methods that exist on .NET Core but not on .NET Framework or .NET Standard 2.0

* Pool CodeWriter ReadOnlyMemory<char> pages These allocations are present in a customer trace I'm looking at, accounting for 1.4% of allocations in the VS process (around 100 MB). The owner of the CodeWriter is already disposable, so making the CodeWriter disposable is trivial, and allows for all ReadOnlyMemory<char> pages added to _pages to be released back to a pool.

Since moving to System.Collections.Immutable 8.0, this extension method is no longer needed.

* Track the containing type of bound attributes for components * Write out the attribute name as a nameof when we have a containingtype. * Use the concrete containing type if we rewrote the parent component. * nameof support for type inferred components * Add line and source span mappings - Special case the synthesized bind entries that don't have a runtime representation - Update spanmapping writing to handle cases where identifiers are escaped * Add nameof test - Adds a test the demonstrates what happens if you declare a function called nameof in a component * Update baselines

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.

…tructure (#10622) This change represents refactoring of the existing co-hosting infrastructure and some effort to make it a bit easier to test.

…SemanticTokensTests # Conflicts: # src/Razor/src/Microsoft.CodeAnalysis.Remote.Razor/Initialization/RemoteClientInitializationService.cs # src/Razor/src/Microsoft.CodeAnalysis.Remote.Razor/Initialization/RemoteClientInitializationServiceFactory.cs # src/Razor/test/Microsoft.VisualStudio.LanguageServices.Razor.Test/Cohost/CohostTestBase.cs

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.

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.

Part of #9519 and #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.

… Build ID 2496558

# Conflicts: # eng/targets/Services.props

… Build ID 2496558 (#10637) 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 #9519 and #10603 This time I did copy the existing tests, because everything was inline so it was easier.

* Add utility for verifying razor diagnostics * Handle `:get`/`:set` in `EditorRequired` checking * Simplify code

…xception failures (#10635) 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 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.

Now that we're not writing to disk, we don't need to validate previously generated files. Fixes #10209

While adding a new ILoggerProvider for integration tests that ignores messages sent after the output is invalid, I noticed a bunch of things to clean up. Importantly, Razor's ILoggerProvider no longer implements IDisposable as the MS.Extensions.Logging version does.

This change adds a new `GetPooledArraySpan(...)` extension method that returns a pooled array as a `Span<T>` with the expected length. This can help avoid bugs that can occur if a pooled array's `Length` is accidental used.

This pull request cherry-picks b8f14d3 to `release/dev17.11`

This is an automatically generated pull request from release/dev17.11 into main. Once all conflicts are resolved and all the tests pass, you are free to merge the pull request. 🐯 ## Troubleshooting conflicts ### Identify authors of changes which introduced merge conflicts Scroll to the bottom, then for each file containing conflicts copy its path into the following searches: - https://github.com/dotnet/razor/find/release/dev17.11 - https://github.com/dotnet/razor/find/main Usually the most recent change to a file between the two branches is considered to have introduced the conflicts, but sometimes it will be necessary to look for the conflicting lines and check the blame in each branch. Generally the author whose change introduced the conflicts should pull down this PR, fix the conflicts locally, then push up a commit resolving the conflicts. ### Resolve merge conflicts using your local repo Sometimes merge conflicts may be present on GitHub but merging locally will work without conflicts. This is due to differences between the merge algorithm used in local git versus the one used by GitHub. ``` bash git fetch --all git checkout -t upstream/merges/release/dev17.11-to-main git reset --hard upstream/main git merge upstream/release/dev17.11 # Fix merge conflicts git commit git push upstream merges/release/dev17.11-to-main --force ```

* Update name away from now-former nation name * Update packages to modern versions * Change package version

…est/Cohost/CohostEndpointTestBase.cs Co-authored-by: Dustin Campbell <[email protected]>

Part of #9519 and #10603 Requires dotnet/roslyn#74402 Removes a little more dodginess in the cohosting tests by actually using the `RazorPinnedSolutionInfoWrapper` for solution checksums, just like the real OOP services.

# Conflicts: # eng/Versions.props

We have tests with baselines that have trailing whitespaces. Our `trimTrailingWhitespace` setting means that those will get modified automatically, breaking those tests. To fix that, I implemented a vscode feature to avoid triming inside regex and strings, so let's use that.

Requires dotnet/roslyn#74280, and won't even compile without it. Part of #9519 This brings signature help to Cohosting. It's a pretty simply PR, for a pretty simple endpoint, as we just delegate, and there is no translation of delegated info. The interesting part here is that we use `System.Text.Json` for the remote signature help service, because it makes more sense to take advantage of the existing Json converters for the potential complexity of the `SignatureHelp` result type.

Having two sln files in the root directory means that `dotnet` CLI commands get confused about what sln to use and need to have it specified. To fix, we just move this solution file into eng, since it's only used for full builds anyways.

Part of #9519 and #10603 After this, all cohost endpoints have test coverage 😁

* Add tests * Fix attribute parsing recovery * Update new baselines * Fix expected missing source mapping * Update pre-existing baselines * Simplify code

I recommend reviewing this commit-by-commit. I took a look at logging to address an integration test issue where we should ignore any exceptions that occur during logging because xUnit's `ITestOutputHelper` is no longer available. Previously, we had swallowed these exceptions across all unit tests as well. However, in unit tests, these exceptions can be an early warning sign of other problems. While addressing integration tests, I ended up taking a more thorough look at logging and ended up re-implementing the log message formatting to reduce string allocations. In addition, I cleaned up a fair number of redundant "no-op" loggers and did an audit of all ILoggerProviders to determine which ones needed to implement IDisposable.

Commits on Jul 3, 2024

Unskip bound attribute test

davidwengier committed Jul 3, 2024

Configuration menu

View commit details

Copy full SHA for 4e25c1d

Browse repository at this point

Copy the full SHA

4e25c1d View commit details

Browse the repository at this point in the history

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update feature branch #10652

Update feature branch #10652

Commits on Apr 29, 2022

Commits on Oct 28, 2022

Commits on Jul 3, 2024

Commits on Jul 4, 2024

Commits on Jul 7, 2024

Commits on Jul 8, 2024

Commits on Jul 9, 2024

Commits on Jul 10, 2024

Commits on Jul 11, 2024

Commits on Jul 12, 2024

Commits on Jul 15, 2024

Commits on Jul 16, 2024

Commits on Jul 17, 2024

Commits on Jul 18, 2024

Commits on Jul 19, 2024