* Wait after File open
* Include assemblyLocation in error message
* Wait for Extension to load to check coloration
* Prevent unwanted references
* Debug upgrade
* Don't load assemblies
- Prior to this I hadn't realized that we were only capturing VS items that were specifically "overloaded" in our "Platform agnostic XYZ" types. This meant that when we were trying to inspect other items on the client capability collection we'd fail to understand them because O# would see the initialize request, deserialize into their own ClientCapabilities at which point all data representing VS' would be lost. To overcome this I created a new `ICaptureJson` type that informs our platform extension converters to maintain the JToken representation of objects.
- Updated our test to be pretty exhaustive to ensure we're capturing all information.
Part of #6328
- We now provide the ability to indicate of a Razor completion items `InsertText` is a snippet.
- With this changeset we can remove some of our pre-existing hack logic on trying to detect minimized or unminimized attributes and instead utilize our new `IsSnippet` tech.
- In updating the RazorCompletionEndpoint to respect the new insert text format that we pass through our system I also found some mishaps in FilterText that I corrected as well. These were exposed by tests.
- Updated existing tests to respect when snippets come from completion items.
- Added new tests to validate snippets
Fixes#6341
* Add VS "like" commit characters to Razor's completion item.
- The new `RazorCommitCharacter` construct allows us to specify whether or not to insert the commit character on insert. Unfortunately this PR doesn't go alllll the way and remove the hacked code to inject VS commit characters onto our O# completion items yet (that's coming).
- Updated call sites to take in the new Razor commit character construct
- Added a new `RazorCompletionOptions` record struct that can indicate when snippest are supported. In all relevant scenarios they are; however, in the legacy editor they're not so we need an option to know if we should use snippet based commit characters or non-snippet based commit characters.
- Updated tests
Fixes#6339
* Add helper method for going from string[] -> RCC[]
- Prior to this change colorized tooltips were implemented by faking the existing of VS types in our language server (see all of the deleted files in the `Tooltip` directory in this changeset) and those fakes would then be serialized to look like VS types. This changeset moves from the fake types to the actual types.
- Our tooltip generation factories went away from O# types entirely in favor of protocol types. In reaction the completion resolve and hover endpoints needed to change since those are consumers of the tooltips.
- In each of the endpoints we needed to convert from VS -> O# types. This is only temporary until we move the endpoints to also consume VS protocol types.
- One extra change that I found important as part of the consumption process was to pull the client capabilities introspection from inside of the tooltip service into the endpoint.
- Updated existing tests to utilize the new protocol types.
Fixes#6331
- Today we have the `IRegistrationExtension` concept which is used to extend Razor's server capabilities to communicate with VS on what "extra" capabilities are enabled. Examples of this are OnAutoInsert and VS' InlineCompletion for snippets. As we're moving more towards consuming VS' protocol types directly it naturally makes sense to flow VS' client capabilities into these extensions so they can make decisions utilizing VS' types which are a superset of proper LSP.
- Changed the `Microsoft.AspnetCore.Razor.LanguageServer.Protocol` package to utilize VS' protocol types and not O#'s. This is a big move because it means all of our "shared" implementation types wont leak O# into the client but then also requires the server to have moved to VS protocol types.
- Added VS internal serializers to the LSP serializer collection. In the end this was harder than I initially thought because the LSP platform APIs don't have a way to add to a list of converters, they only have a way to add to a serializer; unfortunately O# has two sets of converters it looks at so I had to do some hacks to work around this.
- Now that we're passing VS' capabilities into registration extensions I changed the way we consumed the result of a `GetRegistration` call and if it happens to be `null` we now no-op to not add junk to our server capability collection.
- Added tests to validate that we convert capabilities correctly.
Fixes#6332
* Restrict FQN C# code action from appearing in single line directives.
- Found that we'd provide the FQN directive for single line directives and then upon formatting we'd bail because we can't accurately format single line directives. At first I tried digging into why we couldn't format them and turns out the C# formatter returns some really odd edits to us in terms of proper formatting. Once we build in the tech for fully formatting single line directives in the Razor context (ignore what C# tells us) this should enable us to build a good experience around this. For now disabling FQN cleans up what we provide to users.
- Added a test to validate
Fixes#6015
* Address code review comments
- In our last VS insertion I had to do manual ngen updates to ensure our binaries were ngening. I made a woopsie and added an ngen binding redirect to solve an ambiguity ngen. This was a mistake because I also needed to add that binding redirect to our extension so at runtime the right assembly resolved. Our integration tests didn't catch this failure because WebTools also offers the same assembly so instead of barfing our world would use theirs if it couldn't find the right version and things would just work; however, once ngen'd that world expects that the correct assembly exists at the expected location.
- Fix is to add a binding redirect for MS.Extensions.Options at runtime
Fixes#6310 and https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1528365
- In this changeset I went ahead and experimented with a new diagnostic translation approach that I call "inferred". The general idea is that when we encounter diagnostics that aren't in mappable regions / we can't derive where they came from to then attempt to give customers a general idea on where diagnostics are coming from. This means we'll highlight larger diagnostic regions in the document to help guide customers towards problem areas instead of hiding diagnostics entirely. When playing around with this tech I found that we more often than not could show higher quality + significantly more diagnostics to customers without being too noisy.
- So what is "inferred" diagnostic mapping behavior? Effectively it's adding the ability to map "inbetween" known mapping areas. Because languages typically operate on a forward progressing parser model (i.e. errors get propagated downward, not up) we can apply a few heuristics based on some possible states of diagnostics:
1. Diagnostic maps directly to a known sub-language region = return as is (this is strict mapping behavior)
1. Diagnostic intersects with a known sub-language region = scope the diagnostic to the sub-language region to draw attention
1. Diagnostic does not map to any known sub-language region:
1. Diagnostic is inbetween beginning of document and a known sub-language region = Associate diagnostic with the document without a location given diagnostics are typically propagated forward and we'd be highlighting too large an area
1. Diagnostic is inbetween two known sub-language regions = Associate diagnostic with the region between the two known sub-language region because something inbetween those regions is most likely the cause.
1. Diagnostic is inbetween end of document and a known sub-language region = Associate diagnostic with end of closest sub-language region all the way till end of document
- Added tests for the above scenarios
**Left side new (`MappingBehavior.Inferred`), Right side old (`MappingBehavior.Inclusive`)**:
Fixes#6136
- When C# turned on `TextEdit` support for completion items it broke our provisional completion handling. Turns out though that we had a pretty massive gap in how we determined something was a provisional completion and then captured the "correct projection" for that provisional completion. For instance when you type `@DateTime.` what happens is the `.` is understood as HTML so we detect that and inject a fake `.` into the C# buffer and THEN ask for completions (a provisional completion). Problem is that the original projection for the `.` was HTML so if that was represented by line 0 character 10 we needed to also update our projection handling to say actually the projection was line 93 character 15 (to represent the location after the injected `.` in the C# buffer). This way when we went to try and remap TextEdits from C# completion items we would have a valid C# projection to remap the edits; versus before we were trying to do it with the HTML projection which would always fail.
- Now our `TryGetProvisionalCompletions` logic returns a `record struct` that also encapsulates the provisional projection so we can update our projection information in calling code.
- Added a new test for this scenario and updated existing test logic to work with the new return type of provisional completion resolution.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1526095
- When playing with the completion stack I felt that resolve / providing was becoming a bit unweidly and concerns were bleeding across the domain. Therefore I went ahead and split the resolve / provide endpoints apart so the logic is kept separately. This is similar to how we have code actions today as well.
- Also split tests and updated accordingly.
- Ended up needing to promote our completion list cache into a service so both endpoints could interact with the same completion list cache without relying on member state.
* Add Razor Protocol project to ease sharing.
- Prior to this we'd need to re-declare DTO types in the LanguageServer + LanguageServerClient dll's. With the new `Microsoft.AspNetCore.Razor.LanguageServer.Protocol` project there's now a space for all DTO objects that can be shared by server and client.
- I moved the `RazorLanguageKind` type to the protocol assembly as an example and removed its "client" representation from LanguageServerClient.Razor to prove things work.
No issue for this per-say. I found myself going down the path of embedded language redesign and found that I'll need to have a lot of DTO objects so this path made sense.
* Address code review comments.
- Occasionally when building we'd encounter the following error:
The odd thing is this error is inconsistent and happens only on occasion so I'm shotting in the dark here a little bit. We've encountered similar things in the past so I've gone forward and pinned the versions I've seen this error complain about.
- Previously we disabled this tech because users would type `=` and immediately get thrown into a `="$0"` scenario where you couldn't overtype the end quote; however, now VS is smart about this and will allow overtyping, making it appealing to bring this feature back-to-life.
- Changed it so OnAutoInsert calls did not result in HTML formatting. Since we already represent HTML in its proper form in regards to formatting we can rely on the edits from HTML being already formatted. Ultimately this was required because when trying to format HTML returned `=` OnAutoInsert responses we'd then call back into the client to do `OnTypeFormatting` which was unnecessary / unexpcted.
- Re-enabled existing test.
Fixes#4776
Change folding display to always be at the end of the starting line so the text is still visible. This results in something like "Class C..." instead of just "..."
Also be resilient to ranges that don't make sense or start on the same line.
* Wait for local components to be available before running tests
* New test APIs and await folding on launch
* Start capturing LogHub logs
* Don't let log collection errors block further collection
* Harden OutputPane calls
* Don't debug-assert for range errors
* Reduce usage of Debug.Asserto to prevent Integration test breakage and improve diagnosability
* Capture LogHub and Razore Pane when Initialization fails
- This removes the following assemblies from the manifest:
- Microsoft.Extensions.Logging.dll
- Microsoft.Extensions.Logging.Abstractions.dll
- System.IO.Pipelines.dll
- System.Reactive.dll
- System.Runtime.CompilerServices.Unsafe.dll
- System.Threading.Channels.dll
- These seemed to cause errors at runtime.
Part of #6038
Ryan Brandenburg
N. Taylor Mullen
dotnet bot
Allison Chou
dotnet-maestro[bot]
David Wengier
Andrew Hall
