* Updated the tokenizer and parser to operate on SyntaxTokens directly
- The tokenizer and parser now operates directly on SyntaxTokens (Green)
- The SyntaxToken(Red) is now created when the Span is built with the correct parent and position
- All other passes that run after the parsing is complete(TagHelperRewriter etc) will operate on the Red tokens.
- There is now only one type for all SyntaxTokens. They are differentiated by their SyntaxKind.
- Added equivalence checking for tokens
- Updated test code to react
- Regenerated baselines
- Migrated the completion item source provider and the legacy directive completion provider to use the new service.
- Cleaned up duplicate tests that were both verifying common completion functionality.
- Ensured that the legacy `RazorDirectiveCompletionProvider` did not result in additional Razor assembly loads when in C# scenarios.
#2530
- Kept the same behavior as we previously had with Razor directive completions.
- Attempted adding additional functionalities such as lighting up Razor directive completion when completion was invoked on top of Razor directives (non-C#) but ran into issues involving the core HTML editor not consuming the new completion APIs yet. That's something we'll have to re-visit once they move to the new completion APIs.
- Added tests to validate all aspects of new completion APIs.
- Made completion provider turn on and off based off of feature flag.
#1743#1813
- Prior to this change we weren't strict enough with where our smart indenter ran. We made the assumption that every code block could be smart indented and then Roslyn would "do the right thing". However, in nested code block scenarios we found that Roslyn and us would both indent resulting in extra newlines. These changes make the criteria for applying smart indentation a little stricter.
- Updated directive code block parsing to add a C# marker symbol in cases of an empty code block directive.
- Added unit tests to verify new smart indenter behavior.
- Updated existing tests to expect new syntax tree marker symbol for empty directive bits.
- Regenerated baselines.
#2410
- Added ability to understand valid inserts, deletes and replacements for the `@functions` directive (and any other directive that uses our extensible code block bits).
- Added unit tests.
- Updated existing tests.
- Found an issue when completing some C# items the auto-completions would impact the underlying snapshot after we'd captured the change. Fixed this by forcing a reparse when we detect that our understanding of the latest snapshot and the actual latest snapshot diverge.
#2408
- Prior to this change our brace smart indenter would indent JavaScript blocks incorrectly because it didn't take into account where in a Razor file the brace that it was indenting existed.
- Made it so the brace smart indenter only functions in code/metacode locations within the SyntaxTree.
- Updated and added tests to account for new behavior.
#2297
We want to have a way to specify the taghelper descriptors and imports to use while
processing a specific document.
- Added an overload to Process and ProcessDesignTime to take in a list
TagHelperDescriptors and a list of imports
- Added the corresponding CreateCodeDocumentCore overload
- Added GetTagHelpers and SetTagHelpers extension methods for
CodeDocument
- Added the necessary plumbing to use the taghelpers from the
CodeDocument when available and fallback logic.
- Added DocumentImportsTracker and updated background code generation
logic to use the new overload
- Added/updated tests
- First iteration of live share replaced the document tracker factory entirely; however, this will be prone to breaking changes in the future when me make changes to document tracker to not rely on a file path. To pre-emptively prevent breaking changes I added a project path provider that can be overridden in the live share case. Note that one big difference here between old and new is that instead of being a MEF service implementation for the project path resolution we're bringing that to the Workspace service level.
- Added tests to validate the two flows of the default project path provider.
- Prior to this the parser would think that a non-latest reparse request was the latest because the only way we would check to see if a change reference was "latest" would be to do an equality check on the snapshot and `SourceChange`; the issue here was that `SourceChange` was null but the snapshots were the same. Problems could arise with this due to project context changes.
- Added tests to validate the new reparse behavior.
- Renamed `Edit` in the `BackgroundParser` to `ChangeReference` also refactored all the "edit" text in `BackgroundParser` to be `ChangerReference` like.
- Added a new event args to be the DTO between the internal and external parser implementations. This is how we could pas additional information in order to determine "latest" change reference.
#2336
This change intoduces content changes to our project snapshots. We now
know the open/closed state of documents that are initialized by the
Razor project system and listen to the correct data source based on
whether the file is open in the editor.
There are a few other random improvements in here as well like a
workaround for the upcoming name change to our OOP client type.
- MEF is the primary means of resolving the new live share provider therefore we allow it to not be registered.
- The new contract is in the Editor.Razor binary so the LiveShare bits don't have to take the dependency on the windows binary in Razor (has a lot of baggage).
- This is specific to live share but providing a generic way to resolve workspaces didn't seem reasonable given the varying expectations in VS4Mac. If we need to make a more generic solution in the future we'll revisit this; for now this is a straight forward inclusion of live share functionality.
- Added tests to validate the new behavior.
- This unblocks the live share scenario of resolving the remote workspace. We can't rely on the projection buffers to provide the correct workspace because that workspace is wired up too late in the process of opening a Razor file.
#2335
The hash code implementation here is exhaustive when it doesn't need to
be. Slimming this down to a much more reasonable set of things for perf
reasons.
The project snapshot now maintains a RazorProjectEngine as well as set
of Tag Helpers that are known for that snapshot.
Pivoted some more services to be snapshot-centric.
Also added the ability to track .cshtml documents to the project system.
For now most components just ignore document changes.
* Merging changes (from dev branch; doing manually to squash them really)of HTML Parser to be aware of HTML Comments so TagHelpers don't complain about comments as content.
Since the default tag helper provider is used by MVC then MVC should
include it. Now that Blazor is in the mix we shouldn't include it for
all configurations.
Step 1: Add HostProject
This is a somewhat complex addition to the ProjectSnapshotManager. Now
that we accept updates from the underlying IDE project system we need to
coordinate those with the Workspace.
This means that ProjectSnapshot itself now also has a version concept.
Step 2: Introduce a new project system based on CPS
We use project capabilities defined by the Razor SDK to determine
whether to rely on MSBuild evaluation to detect the configuration or
whether to fallback to assembly-based detection.
Step 3: Flow RazorConfiguration everywhere
We use now expose the RazorConfiguration to the language service and
editor. This means that we no longer need to detect the project's
configuration asynchronously, it happens much faster now.
N. Taylor Mullen
Ryan Nowak
Nate McMaster
Ben Adams
Ajay Bhargav Baaskaran
Ajay Bhargav Baaskaran
Ryan Nowak
Kiran Challa
Artak
Artak Mkrtchyan