Loading multiple versions of a task assembly result results in MSBuild on .NET Core to fail.
Addressing this by moving the tasks in to the Sdk and renaming it. This should avoid
immediate issues for a 2.1 and 2.2 project co-existing and future proofs 2.2 and later.
Fixes https://github.com/aspnet/Razor/issues/2553
- Prior to this we had a `BackgroundDocumentGenerator` that would constantly be updating generated code containers. With this changes we've changed the details in how a `GeneratedCodeContainer` can be mutated. It can now be touched from any thread and is updated when an underlying `DocumentSnapshot` has available content. However, if a generated output comes through that's older then the last seen output we no-op.
- Removed `BackgroundDocumentGenerator` SetOutput logic.
- Updated tests to react to new behavior of `GetGeneratedOutputAsync`.
- Added new test to verify getting generated output results in the setting of the host documents output.
- The issue was that the `executeChildContentAsync` call was stopping the invocation of the `_endTagHelperWritingScope`. Therefore, we'd never finish the TagHelper content scope and all following content would be ignored.
- Added two tests to validate the new functionality.
#2561
* Auto generate CSharp syntax tree nodes
- Auto generated syntax nodes, visitors and factories
- Renamed RazorComment to RazorCommentLiteral to avoid a conflict
- Modified the Visit() contract
- Added new SyntaxKinds
- Regenerated baselines
* 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
The new Formatter is used in debugger display, to resolve#2264
The next iteration (assuming we like this) will be to replat our testing
baseline infrastructure on top of this, and then start sharing that with
Blazor - related to #2265.
I found when implementing debugger display that I was duplicating a lot
of details between testing and this.
I also want to convert the Blazor tests to use shared infrastructure.
Right now the Blazor tests use a modified version of the Razor
infrastructure that has different features.
Initial infrastrucure for a better html parser
- Added new syntax node types that follow Roslyn's red/green pattern
- Modified the html text node in the current syntax tree to use the new
nodes
- Updated test infrastructure
- Generated 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
- Some time spans were too aggressive for parsing a Razor file on a slow environment.
- Fixed an obvious race where we'd expect 0 pending notifications when it was possible to be in the process of clearing notifications.
#2506
- When a surrogate pair is about to be split down the middle we reduce the size of our split by 1 character. This way we split right before a surrogate pair. In the case of zero width joiners, if we split on a zero width joiner we still render valid bytes because the zero width joiner by itself can stand alone.
- Added tests for the various split cases.
#2470
- Added the necessary infrastructure to serialize and verify the syntax
tree
- Updated ParserVisitor to be overrideable
- Made CSharpVerbatimBlockTest to use baselines
Nate McMaster
Ryan Nowak
N. Taylor Mullen
Pranav K
Ben Adams
Ajay Bhargav Baaskaran
Ajay Bhargav Baaskaran
Marcin Burak
Ryan Nowak
Artak
Doug Bunting
Daniel Eisterhold