* Fix C# ambiguity errors in old Razor editor in VSMac.
- Fixed by updating virtual C# to be *.ide.cs instead of *.g.cs
- Turns out Razor in VSMac overloads the .g.cs file suffix for projection buffers which then results in our "background C# file generation" thinking files are actually open when they're not. SO to elaborate, when you open a .razor file in the old editor in VSMac you get 3 files:
1. The .razor file you opened
2. A .razor.g.cs file that represents the generated C# in the projection buffer
3. Another .razor.g.cs file that represents the "closed file" representation of that document. Once opened we empty out our background document to avoid name collisions.
When I fixed how we populate C# LSP documents into the C# workspace I changed the VSMac number 3 above from ".g.cs" => ".razor.g.cs" because that's how the LSP system looks up documents too; however, this introduced a conflict with the projection buffer representation of the old editor. That conflict was a problem because when we went to try and "empty" our closed file representation the VSMac side would do a [lookup](bcf3d00848/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.TypeSystem/DynamicFileManager.cs (L95-L98)) to see if the file was open, and if it was ignore the "empty" behavior. Therefore both the projection and the closed file representation would exist simultaneously causing ambiguity errors
- TO fix the above I went ahead and normalized where we create C#/HTML virtual file paths evvvvverywhere. Ultimately these file paths now come from ourr language server feature options which was already a MEF service. In addition I went from .g.cs to .ide.cs to avoid conflicts with the projection buffer.
- Updated tests across the board to account for this new behavior.
Fixes#6630 and https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1582970
* Fix build.
* Fix build part 2
* ide.cs => ide.g.cs
* Fix tests.
* Add TextMate information to VSMac Addin.
- Update TextMate information for VSMac.
- Added new MSBuild goop to copy VSWin's TextMate pieces into VSMac's addin.
- As part of this I had to update our mpack generator to respect a sub-folder indicator.
* Add aspnetcorerazor.tmLanguage.json to Addin
* Fix project.razor.json generation on Mac.
- Turns out project system interactions on mac still use windows style paths. Meaning, if we query MSBuild for information like the `obj` directory we'll get the path back with `\`. These paths then explode when passed to normal .NET APIs. This fix translates all MSBuild / local file system interactions to utilize `/` on Macs.
- Unfortunately due to the MonoDevelop APIs these sections can't be properly tested without extensive re-work. This was already the precedent so #yolo
* Address code review comments.
In extract to code behind, there are cases where the setup is not fully ready for the compiler to accurately generate a namespace. Luckily they provide a public extension point to get the namespace for a document, which handles fallback behavior and failure. Use that in the action provider to determine if a namespace is accurately available. If it is, fill the action params with that namespace and use for generating the code rather than recalculating it again.
Fixes#4441
- This is the final part to #6618 to enable completion resolve to acquire formatting options for complex text edits so it can properly format text edits
- We now expose a new endpoint on the client under `razor/formatting/options` that will return the most recent understanding of formatting options
- To make this possible updated the `FormattingOptionsProvider` API to take a `Uri` instead of a document snapshot.
- Updated tests accordingly
Final part of #6618
* Add support for remapping TextEdits & AdditionalTextEdits at resolve time.
- Migrated our old `CompletionResolutionHandler` logic for post-processing C# completion items to our new single server completion system.
- One current gap is that the old system used to lookup active formatting options on the client to understand if snippets should be formatted with/without tabs etc. For now I'm using defaults but in a follow up PR i'll light up the real formatting options acquisition logic.
- As part of this PR there were several pieces of code that could be re-used so I refactored them out. The `TestRazorFormattingService` is a prime example (especially now that completion resolve depends on it).
- Did a few updates to the API so it was clear what type of formatting service you'd be getting (aka should it be HTML enabled?).
- Added a test that validates that we get and remap text edit completions properly (I use `await`). I couldn't find a corresponding C# completion item that utilizes `AdditionalTextEdit`s.
## Enables
Most of #6618
* Address code review comments.
- Prior to this C# snippets were wrapped/unwrapped at the endpoint layer. This means anyone trying to format a snippet would need to manually wrap/unwrap their own snippets. The logic fit well into the existing formatting service so I migrated the logic there.
- Another aspect of this that's a little disconnected is that when applying formatted snippet edits I found that edits wouldn't get "minimialized" prior to collapsing which would result in unminified edits returning to the client. At completion time (what I will eventually be doing as part of #6618) this was highly troublesome because completion is sensitive to the "end of the edit" area. Meaning if you complete `await` and the await has a complex text edit that gets formatted the `t` in `await` needs to be the absolute last thing in the edit to not obstruct the cursor; however, without the minimal edit change that doesn't actually work properly. I imagine this was just an unintentional oversight and wasn't quite sure how to test this (although I do test it in the completion resolve tests that are coming latere) so I included it here.
- Currently there's no direct tests of this method it looks like. Although in a follow up PR for #6618 I'll be formatting resolved completion items.
Part of #6618
- Not sure why we originally were changing the file extension of our generated documents to not include the Razor file extension. This aligns LSP's understanding of file paths with the dynamic file info understanding. Given how much tribal knowledge / convention is baked into the `.g.cs` ending we should probably build a factory; however, getting that factory to work across all products (VS, VSCode, VSMac) is less than simple. For now here's the quick fix.
- The original `CSharp_Operator_Triggered` test was an incorrect scenario. For instance, C# doesn't typically trigger completions off of typing `(`. Instead I migrated the test to do a `DateTime.` variant with `.` being the trigger. The only catch then was that our generated C# document did not contain `using System` so I had to update our generated code document bits to properly generate the using statement.
Part of #6618
- Updated C# portions of our delegated completion list provider tests to utilze the real C# server and simplified the testing model.
- Maintained a lot of pre-existing tests because we don't have similar capabilities for HTML
- These tests will be more widely used upon completion of #6618 where we'll want to resolve text edits (this is a leadup).
Part of #6618
- Found that for trigger character based tests completion results weren't being returned. Meaning, invoking completion at `@if (|)` wouldn't result in any completions. I tried this with a few different samples and all didn't work.
- Updated the delegated completion list provider to take in a CSharp server.
- Shamelessly stole 90% of this from @allisonchou
- Mac & windows boxes represent file paths differently `/` versus `\`. Sadly at the portion where our system intersects with project systems (CPS or VSMac's custom) file paths need to fall back to a platform equivalent so that files can properly be looked up. This changeset adds a platform check in order to special case this scenario. Didn't feel great about this path but I don't have a better way without making external-to-razor project system specific changes on both VSWin and VSMac.
- This changeset changes how our `DocumentSnapshot` system caches its output. Previous it relied on a secondary system to dig deep into a `DocumentSnapshot`, extract its "generate output task" and then hold onto a reference of that. In this change I expand `DocumentState` to be "code document reference aware"; meaning, if someone is referencing the generated output then the output is maintained so we don't need to re-parse / compute data. Ultimately this ends up bringing our new system back into par with our existing perf and even surpassing it in quick typing scenarios (multiple document states flowing simultaneously).
- With this changeset and some rudimentary testing I saw a 10% reduction in overall cache misses compared to what exists today while also maintaining simplicity.
- Added tests to validate we do the right thing at referene / cache time.
Final part of #6043
* Remediating Azure Artifacts Configuration Issues.
- Porting from [this PR that was done on the wrong repo](https://dev.azure.com/dnceng/internal/_git/dotnet-razor-tooling/pullrequest/23705?_a=files). I tried to maintain branch / naming etc. but wasn't able to maintain author info. Seems like Azdo threw away the details maybe?
* Address code review comments.
Microsoft.AspNetCore.Mvc.Razor.Extensions.Tooling.Internal , Microsoft.AspNetCore.Mvc.Razor.Extensions.Version1_X.Internal.Transport , Microsoft.AspNetCore.Mvc.Razor.Extensions.Version2_X.Internal.Transport , Microsoft.AspNetCore.Razor.Symbols.Transport , Microsoft.CodeAnalysis.Razor.Tooling.Internal
From Version 7.0.0-preview.5.22357.2 -> To Version 7.0.0-preview.5.22364.1
- On its surface having a C#/HTML output version seems appealing; however, in practice we've never used it because the `SourceText` that stores the output already versions this information. Also, when digging through the code I found that every time we'd parse a file we'd aggressively be generating the C#/HTML docs (even when we don't need it) and simultaneously we'd also be doing massive string equals checks to try and understand versioning. This changeset removes all of that.
- Updated tests to remove the C#/HTML output checks because they no longer exist
- Made `DocumentState` nullable enabled.
Done as part of #6043 although it technically could stand on its own.
* Replace GeneratedDocumentContainer & deps.
- This changeset effectively removes all `GeneratedDocumentContainer` assets. Let me explain what effectively this means. Prior to this whenever a Document was parsed there was a decoupled system that attempted to understand the "latest document" and capture its generated output in one of these generated containers. That decoupled system was also responsibel for publishing generated C#/HTML to the client. Meaning, whenever it saw a change to its generated C# container or HTML container it'd push a notification to the client to update C#/HTML buffers. The issue with the old system is that it was so decoupled from the rest of the tooling system that things like "open/closing" files couldn't be understood meaning we couldn't reset document content when closing an unsaved document. For another in-depth understanding of this see [this](https://github.com/dotnet/razor-tooling/issues/6043#issuecomment-1185969172).
- The new system presents itself as a service (the `GeneratedDocumentSynchronizer`) and as documents change via project updates, document additions or document changes this synchronizer is notified via the `DocumentProccessedListener` infra. Upon notification it can then re-dispatch those "processed" updates to a C#/HTML publisher. This new path enables us to be open/close document aware (document changes) so that upon closing/open we can re-push C#/HTML to the client effectively fixing this issue (#6043).
- One huge benefit of moving this way is the sheer amount of code we can delete. Was able to remove our generated document containers, the factory for them, the store for them, their tests, and all their old fragile consumption bits.
- A piece that's missing from this PR is that we used to capture references to generated C# computations via the `ReferenceOutputCapturingContainer` which is now removed. It had to be removed because it can no longer hook into these generated document stores (they don't exist). I plan to replace this in follow up PRs. As a point-in-time measurement the perf may still be better due to how much less work we need to do; however, we do cache miss more so that's debatable. In my follow ups we are actually able to significantly exceed pre-existing perf measurements.
- Had to update our O# plugin handling of document processed listeners upon removal of the generated containers.
- Added new tests and updated pre-existing ones.
Mostly fixes#6043 with the exception of the slight cache miss regression (coming soon)
* Address code review comments.
- Removes even more code!
- This expands the `DocumentProcessedListener` infra to pass the "processed" document output. The reason why this is important is because once we process a document there's no guarantee that the output wont get GC'd. Therefore, we capture the output that we already processed and pass it through to anyone who cares. In the end this will help sub-systems who want to reduce how frequently they accidentally re-parse documents that are actively being introspected.
- I decided not to expand our diagnostic publisher to use the processed output becaues we have separate plans to move the diagnostic publishing system to "pull" which will result in the entire publisher getting reworked.
- Updated all call sites and tests.
Part of #6043
- Way way back in the day I wrote `UnsynchronizableContentDocumentProcessedListener` as a way to "fix up" generated C#/HTML when things went out of wack. For a long while I ran local bits with a breakpoint in the "do something" portion of the code AND even ran with the code deleted and breakpoint never hit + things never broke. Therefore, this is dead code and given I plan to repurpose the document processed listener infra going to nuke this code to reduce noise.
- Also removed test and service registration
Part of #6043
- This is preliminary work for changing how we update generated C#/HTML content on the client. The end-goal is to utilize the open document generator's `DocumentProcessedListener` infrastructure to provide a "Generated synchronizer" that listens to processed documents and pushes those processed document updates down to the client.
- I also plan to remove the `ReferenceCaptureOutputContainer` tech which utilizes a batching work queue to control how often we set generated output given we'll be changing how generated output is propagated.
- Changed the OpenDocumentGenerator tests to utilize the non-legacy dispatcher + fully test the new infrastructure.
Part of #6043
- Originally found in this Integration test CI failure: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6414782&view=results
- This ended up revealing a few issues:
1. Prior to this changeset formatting tests would wait for folding ranges to be available before attempting to format anything. In the above CI failure those checks timed out and the screenshots included also showed that no folding ranges were available. This indicates there might be a secondary issue where folding ranges ar ea little flakey. I've filed [this](https://github.com/dotnet/razor-tooling/issues/6592) to track re-enabling code folding tests and moved our existing formatting tests off of folding ranges being available to waiting for semantic classifications
2. With the introduction of [this](https://github.com/dotnet/razor-tooling/pull/6531) change we started accurately formatting content after directive bodies. Updated our baselines for formatting tests to capture this new requirement.
- As part of this work I also found that the existing `WaitForClassificationAsync` was a little misleading because it defaulted to waiting for Razor component classifications. I've gone ahead and renamed the existing method to `WaitForComponentClassificationAsync` to be extra clear what's being waited for. As an extra reaction I added a general `WaitForSemanticClassificationAsync` that's now used in Razor formatting tests so we can wait for semantic Razor transitions.
- We're flighting "true" to all internal users in 17.3 builds; however, for 17.4 we're going to be on-by-default so we have an entire release to catch and address issues. If this ends up being a problem we can remotely turn it off OR we can physically swap the switch.
Fixes#6421
* Use a batching work queue to prevent repeated work
At the very least this cuts the amount of work in half, as we hook up two events to this one method, so every text change would call this twice. Now the work queue ignores the first one for us.
Secondly, the timeout is very short, but still long enough that fast typing will not cause repeated work until there is a slight pause.
* Remove unused properties
Previously we reduced how often we would do a bunch of work, but it turns out a lot of that work wasn't ever used anyway. Seems to me like its better to just not do the work in the first place.
* Decrease timeout
* Remove debug code
* Doc
dotnet-maestro[bot]
Sandy Armstrong
N. Taylor Mullen
Allison Chou
David Wengier
Andrew Hall
dotnet-maestro[bot]
DoctorKrolic
