- The platform changed how the text structure navigator APIs behave at the edges of words. Because of this we need to re-calculate how we capture word spans. For instance when we'd ask for the wordspan at `p|\r\n` we'd get `\r\n` without this change set resulting in no snippets.
### Before
### After
Fixes#4599
* Fix inaccurate HTML/CSS diagnostics on C#.
- The CSS diagnostic system didn't recognize the C# portions of the document and was then warning about those portions of the document. It's expected that we'd get a diagnostic in this case; however, we should be filtering HTML diagnostics that map to C# literals because they can't see the C# literals properly.
- Added a test to capture this case.
### Before
### After
Fixesdotnet/aspnetcore#36321
* Update src/Razor/src/Microsoft.AspNetCore.Razor.LanguageServer/Diagnostics/RazorDiagnosticsEndpoint.cs
Co-authored-by: David Wengier <david.wengier@microsoft.com>
* Fix tests
Co-authored-by: David Wengier <david.wengier@microsoft.com>
- Catches IOException which seems(?) to be out of our control. @ryanbrandenburg please let me know if this isn't the right fix.
Fixes: dotnet/aspnetcore#35306
- Pinning all of the LanguageServer.Protocol packages so that we don't get conflicts. At runtime the Client.Implementation assembly we depend on will be binding redirected to a version that has the same protocol dependency.
Fixesdotnet/aspnetcore#36945
* Fix closing HTML elements when nested and next to others.
- **Issue:** Found another compiler quirk since we can't rely on looking up specific SyntaxTokens by position :(. Gist is that since we can't lookup token by position and have to rely on `GetOwner` we can occasionally get a node that's in front of our cursor. In the nested HTML case of `<first>|<second>` you'd get `<second>` as the owner.
- **Fix:** Gist is I added two more sections to our compiler quirks helper in our auto-closing behavior method. It's sad but works.
- Updated tests to reflect this new scenario.
Fixesdotnet/aspnetcore#36906
* Fix and add more tests.
- **This issue:** When multiple languages weave on the same line the beginning of the line line is used for language-configuration.json lookup. Prior to this we'd only have the ending portion of our directives be C#. This meant that the IDE would look at the beginning of hte line, find Razor's grammar and then apply its indentation rules. In Razor's case it tries to lookup HTML tags (the generic `<string>`) and increase indentation based on that.
- **The fix:** Provide a new directive language-configuration.json grammar that's not Razor and map all directives to it. Now this isn't the most ideal fix because technically what we really want is to have a Razor, HTML and C# grammar etc.; however, we currently have our Razor grammar usurping the HTML grammar which puts us in this position of needing to build a new language-configuration.json. I didn't want to split out the Razor / HTML grammar pieces due to how close we are to Preview5 snap but it's something we should consider in the future.
- Updated all Razor directives to be more generic (it should have been this way to begin with) and went from `meta.directive.somethingspecific` to `meta.directive`. This means I was able to associate the `meta.directive` scope with the new razordirective language-configuration.json
- Updated our grammar tests to reflect this change.
### Before
### After
Fixesdotnet/aspnetcore#35780
- The platform sends one last pull diagnostic request on document close. Prior to this change we'd gracefully no-op if we couldn't find one of our documents; however, the expected behavior is to clear all diagnostics for that closed/deleted document. In the end this is a super simple change.
- Updated tests to reflect the new behavior.
- Added a CTI work item to expand our existing coverage of closed/deleted Razor documents in regards to C# diagnostics: https://github.com/aspnet/Tooling-ManualTests/issues/1503
### Before
### After
Fixesdotnet/aspnetcore#36940
* Allow synchronizer to handle removed documents.
- Occasionally virtual documents get removed in the midst of trying to synchronize. I found that after deleting a Razor file we'd throw because we couldn't lookup the HTML virtual document. Updated the synchronizer to respect this scenario and added a test as well.
- Found this when investigating https://github.com/dotnet/aspnetcore-tooling/pull/4251
* Update src/Razor/src/Microsoft.VisualStudio.LanguageServer.ContainedLanguage/DefaultLSPDocumentSynchronizer.cs
Co-authored-by: Allison Chou <allichou@microsoft.com>
Co-authored-by: Allison Chou <allichou@microsoft.com>
* Update dependencies from https://github.com/dotnet/aspnetcore build 20210924.8
Microsoft.AspNetCore.Razor.Language , Microsoft.AspNetCore.Razor.Internal.Transport , Microsoft.AspNetCore.Mvc.Razor.Extensions.Version2_X , Microsoft.AspNetCore.Mvc.Razor.Extensions.Version1_X , Microsoft.AspNetCore.Mvc.Razor.Extensions , Microsoft.AspNetCore.Testing , Microsoft.CodeAnalysis.Razor
From Version 6.0.0-rtm.21474.12 -> To Version 6.0.0-rc.2.21474.8
Dependency coherency updates
Microsoft.Extensions.Configuration.Json,Microsoft.Extensions.Logging,System.Diagnostics.DiagnosticSource,System.Resources.Extensions,System.Text.Encodings.Web,Microsoft.Extensions.DependencyModel,Microsoft.NETCore.App.Ref,Microsoft.NETCore.BrowserDebugHost.Transport,Microsoft.NETCore.App.Runtime.win-x64,Microsoft.NETCore.Platforms
From Version 6.0.0-rtm.21472.13 -> To Version 6.0.0-rc.2.21470.23 (parent: Microsoft.CodeAnalysis.Razor
* Update dependencies from https://github.com/dotnet/aspnetcore build 20210924.23
Microsoft.AspNetCore.Razor.Language , Microsoft.AspNetCore.Razor.Internal.Transport , Microsoft.AspNetCore.Mvc.Razor.Extensions.Version2_X , Microsoft.AspNetCore.Mvc.Razor.Extensions.Version1_X , Microsoft.AspNetCore.Mvc.Razor.Extensions , Microsoft.AspNetCore.Testing , Microsoft.CodeAnalysis.Razor
From Version 6.0.0-rtm.21474.12 -> To Version 6.0.0-rc.2.21474.23
Dependency coherency updates
Microsoft.Extensions.Configuration.Json,Microsoft.Extensions.Logging,System.Diagnostics.DiagnosticSource,System.Resources.Extensions,System.Text.Encodings.Web,Microsoft.Extensions.DependencyModel,Microsoft.NETCore.App.Ref,Microsoft.NETCore.BrowserDebugHost.Transport,Microsoft.NETCore.App.Runtime.win-x64,Microsoft.NETCore.Platforms
From Version 6.0.0-rtm.21472.13 -> To Version 6.0.0-rc.2.21470.23 (parent: Microsoft.CodeAnalysis.Razor
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
* Prioritize TagHelper/directive attribute completions when applicable.
- So unintentionally this issue ended up solving 2x issues at once, I apologize for the conflated concerns!! I'll leave comments in this description detailing how/why it did two.
- When a user is trying to get attribute completions today we show HTML & attribute completion items. Both of those completion item sets get weaved amongst each other and get shown as one jointly sorted list. Now the unfortunate side effect of this is that when you have a custom component / TagHelper we spit out every possible completion item which can lead to really confusing scenarios. To fix this I took the approach of adding `SortText` to our internal `RazorCompletionItem` type to allow us to sort TagHelper completion items prior to any HTML completions.
- Now similarly when trying to get directive attribute completions we have the same issue as above; however, that scenario is slightly different. Reason being in an ideal world for directive attribute completions i.e. `<strong @|>` we'd simply not request HTML completions because it's following an `@` symbol; however, with the Razor language servers current design this isn't easily done. We therefore can also utilize this sort text approach to prioritize directive attribute completions above HTML completions.
**Details:**
- Expanded `RazorCompletionItem` to support `SortText`.
- Added a `CompletionSortTextHelper` class to make picking `SortText`'s simple. For now I've added 2 types, Default and High priority
- Updated our completion endpoint to utilize the `SortText` from our `RazorCompletionItem`s. This is where I unintentionally fixed issue dotnet/aspnetcore#30255. Reason being is that we had to pick a default for `SortText` when not provided. I chose the display text because technically that's what a user sees when typing. With this in mind a directive attribute completion USED to use `InsertText` for its sort text. Meaning, it'd display `@bind` but would be sorted off of `bind`. Now that `SortText` defaults to the display text it means the `@` in `@bind` sorts the item to the top of the list. I could take this one step further and be explicit in the `SortText` for directive attributes; however, we actually gain a little bit of perf here because if `DisplayText == SortText` then we can omit the `SortText` and platform will sort off of the display getting us our expected result.
## Directive Attribute Completion:
### Before
### After
## TagHelper Attribute Completion:
### Before
### After
Fixesdotnet/aspnetcore#30255Fixesdotnet/aspnetcore#35848
* Address code review comments.
* Fix tests
* More test fixes
[main] Update dependencies from dotnet/aspnetcore
- Coherency Updates:
- Microsoft.Extensions.Configuration.Json: from 6.0.0-rtm.21471.19 to 6.0.0-rtm.21472.13 (parent: Microsoft.CodeAnalysis.Razor)
- Microsoft.Extensions.Logging: from 6.0.0-rtm.21471.19 to 6.0.0-rtm.21472.13 (parent: Microsoft.CodeAnalysis.Razor)
- System.Diagnostics.DiagnosticSource: from 6.0.0-rtm.21471.19 to 6.0.0-rtm.21472.13 (parent: Microsoft.CodeAnalysis.Razor)
- System.Resources.Extensions: from 6.0.0-rtm.21471.19 to 6.0.0-rtm.21472.13 (parent: Microsoft.CodeAnalysis.Razor)
- System.Text.Encodings.Web: from 6.0.0-rtm.21471.19 to 6.0.0-rtm.21472.13 (parent: Microsoft.CodeAnalysis.Razor)
- Microsoft.Extensions.DependencyModel: from 6.0.0-rtm.21471.19 to 6.0.0-rtm.21472.13 (parent: Microsoft.CodeAnalysis.Razor)
- Microsoft.NETCore.App.Ref: from 6.0.0-rtm.21471.19 to 6.0.0-rtm.21472.13 (parent: Microsoft.CodeAnalysis.Razor)
- Microsoft.NETCore.BrowserDebugHost.Transport: from 6.0.0-rtm.21471.19 to 6.0.0-rtm.21472.13 (parent: Microsoft.CodeAnalysis.Razor)
- Microsoft.NETCore.App.Runtime.win-x64: from 6.0.0-rtm.21471.19 to 6.0.0-rtm.21472.13 (parent: Microsoft.CodeAnalysis.Razor)
- Microsoft.NETCore.Platforms: from 6.0.0-rtm.21471.19 to 6.0.0-rtm.21472.13 (parent: Microsoft.CodeAnalysis.Razor)
[main] Update dependencies from dotnet/aspnetcore
- Coherency Updates:
- Microsoft.Extensions.Configuration.Json: from 6.0.0-rtm.21470.22 to 6.0.0-rtm.21471.19 (parent: Microsoft.CodeAnalysis.Razor)
- Microsoft.Extensions.Logging: from 6.0.0-rtm.21470.22 to 6.0.0-rtm.21471.19 (parent: Microsoft.CodeAnalysis.Razor)
- System.Diagnostics.DiagnosticSource: from 6.0.0-rtm.21470.22 to 6.0.0-rtm.21471.19 (parent: Microsoft.CodeAnalysis.Razor)
- System.Resources.Extensions: from 6.0.0-rtm.21470.22 to 6.0.0-rtm.21471.19 (parent: Microsoft.CodeAnalysis.Razor)
- System.Text.Encodings.Web: from 6.0.0-rtm.21470.22 to 6.0.0-rtm.21471.19 (parent: Microsoft.CodeAnalysis.Razor)
- Microsoft.Extensions.DependencyModel: from 6.0.0-rtm.21470.22 to 6.0.0-rtm.21471.19 (parent: Microsoft.CodeAnalysis.Razor)
- Microsoft.NETCore.App.Ref: from 6.0.0-rtm.21470.22 to 6.0.0-rtm.21471.19 (parent: Microsoft.CodeAnalysis.Razor)
- Microsoft.NETCore.BrowserDebugHost.Transport: from 6.0.0-rtm.21470.22 to 6.0.0-rtm.21471.19 (parent: Microsoft.CodeAnalysis.Razor)
- Microsoft.NETCore.App.Runtime.win-x64: from 6.0.0-rtm.21470.22 to 6.0.0-rtm.21471.19 (parent: Microsoft.CodeAnalysis.Razor)
- Microsoft.NETCore.Platforms: from 6.0.0-rtm.21470.22 to 6.0.0-rtm.21471.19 (parent: Microsoft.CodeAnalysis.Razor)
- Found a realllly interesting interaction with O# framework where if something imports an `IEnumerable` based service then when the outer service collection disposes it removes all entries from the imported `IEnumerable`. Because of this what would happen in our scenario is that we'd close a solution, the file change detector enumeration would be emptied and then in our file change detector manager's "Dispose" method we'd attempt to ` Stop` all active file change detectors; welllll in this situation the enumeration would be empty so `Stop` would never be called. All of those file watchers still had references to the old project snapshot manager dispatcher and would then enqueue tasks to be run on an old `ProjectSnapshotManagerDispatcher` that dispatcher would then operate in uncharted territory and ultimately leak loads of requests/information.
- The fix is rather simple, since the O# framework clears the imported enumeration we just need to `ToArray` it to ensure that the framework doesn't empty our collection.
- I have some doubts that this entirely fixes the below issue; however, It's most likely a part of it.
Part of dotnet/aspnetcore#35787
Allison Chou
David Wengier
Tony Xia
Jinu
Ryan Brandenburg
David Wengier
N. Taylor Mullen
Youssef Victor
Gen Lu
dotnet-maestro[bot]
Tanay Parikh
