- 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
- 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
A common cause for runtime view compilation failure in MVC is when an application is published
without reference assemblies. MVC usually handles this at compilation, by looking for specific
error codes. More recently, TagHelper discovery fails with an not-so-helpful error message in this
scenario. This change attempts to add a little more error checking to cover the most common cases
- Allow identical `@using` directives in the primary document. This means that if a user types `@using System` twice in the primary document (i.e. `Index.cshtml`) then we'll generate that using statement twice; this enables proper C# IntelliSense to light up on both using statements and allows auto-completion to work because there's no more magical distinction logic for Razor code that is in the current document.
- Prior to this change if you had two identical using statements in the same document one would be in no-mans land mapped to nothing (not C#, not HTML) and the other would be mapped to C#; the second a user differentiated the two statements (i.e. adding a `.`) we'd distinctify the using statements resulting in an invalid completion.
- This PR has an end-user impact where they will now receive the normal C# warning about having duplicate using. I treated this prior behavior more as a bug because we threw away the first using directive instance which impacted editing and in general was a silly thing to correct for the user.
- Added new integration test showing how using directives are not de-duplicated in the primary document.
#1255
- This is part of a fix for #1255 - this change enables signature help in implicit expressions by improving the partial parsing. We're now smart enough about the contents of an implicit expression and attempt to balance parenthesis to determine if we should not full parse.
#1255
Ryan Nowak
N. Taylor Mullen
Ajay Bhargav Baaskaran
Ajay Bhargav Baaskaran
Marcin Burak
Ryan Nowak
Artak
Doug Bunting
Daniel Eisterhold
Pranav K