- 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
For some inexplicable reason timestamps returned as part of the test often show up
as being different resulting in test flakiness. We've manually verified that this
is not a product issue and builds are correctly incremental on xplat. See #2219
for past discussions.
Fixes https://github.com/aspnet/Razor/issues/2503
* 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
ASP.NET CI
Ryan Nowak
N. Taylor Mullen
Ajay Bhargav Baaskaran
Ajay Bhargav Baaskaran
Nate McMaster
Nate McMaster
Pranav K
Marcin Burak
Ryan Nowak
Artak