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.
This change will allow someone extending Razor to use generic type
parameters in generated classes.
There's no user-level extensibility provided here yet, as in there is no
language support for adding type parameters.
- Prior to this imported `@page` directives would flow through the Razor system without error. This resulted in inconsistent behavior between MVC and Razor. Now, imported `@page` directives result in diagnostics on the page directive node.
- Added two tests to verify that we still treat views with imported page directives as Razor pages BUT we also log a diagnostic on the page directive node.
- Renamed the `ViewComponentDiagnosticFactory` class to `RazorExtensionsDiagnosticFactory` so it can be used for more than just view component diagnostics. This way we can ensure that our diagnostics don't end up overlapping.
#1503
- Rename `CSharpRenderingContext` => `CodeRenderingContext`.
- Rename `CSharpCodeWriter` => `CodeWriter`
- Rename `BasicWriter` => `IntermediateNodeWriter`
- Rename `...BasicWriter` => `...NodeWriter`
- Made `CodeRenderingContext` a public abstract API. Left temporary TagHelper pieces in the class since these will be removed soon.
- Moved several `CodeRenderingContext` methods into extension methods. These make use of the Items collection.
- Moved the reporting of missing code target extensions into the `ExtensionIntermediateNode`. This is the integration point of `CodeTarget`s and `CodeRenderingContext`s; therefore, it made more sense existing there.
- Left SetRenderChildren/SetRenderNode as extension methods due to how they're wired up. Aka, to create a `CodeTarget` you need a `CodeRenderingContext`... To Create a `DocumentWriter` you need a `CodeTarget`... To set the render methods on the context you need a `DocumentWriter`.
- Updated tests to utilize the new code renering constructs.
- Moved code generation testability features from `CSharpLoweringPhase` to the `CodeRenderingContext.Items`.
#1043
- Added an inner pass inside of the intermediate lowering phase to determine which directives get flowed to the final document. There were many ways to accomplish this but in order to keep the last wins mechanic for non-auto imported directives I had to let the directives get created and then removed based on if they were inherited.
- Added error case if a user attempts to import a block directive with a `FileScopedSinglyOccurring` directive usage.
- Added test cases that validate directives are properly inherited at the intermediate lowering phase.
- Updated a few tests that had incorrect assumptions.
- Left the default directive passes alone in regards to determining the "imported" directive to enable users to add their own model, inherits, etc. directives that take precedence.
- Normalized the passes in the intermediate lowering phase to handle directives identically (we don't conditionally lower anymore).
#1376
- Added error case that enforces whitespace in between directive tokens.
- Upon encountering invalid directive tokens/states we bail out of parsing and log an appropriate error.
- Raised directive parse errors to the IR layer. This is slightly hacky given the parsers limitations; we swap out the error sink temporarily to capture all directive parser errors and then shove the errors collected onto the directives chunk generator.
- Added a `MalformedDiretiveIRNode` and corresponding pass to represent directives that are in an invalid state. Chose to not take the path of using the default `DirectiveIRNode.Diagnostics` member to enable users who are extending directives to only ever have to work with "valid" directives. If they want to work with malformed directives they can search the IR document for their malformed counterpart and handle it separately.
- Updated existing test expectations
- Removed some existing tests that were no longer valid (we don't call into user code if a directive is malformed).
#1173
- Added a `Diagnostics` and `HasDiagnostics` properties to `RazorIRNode`. The `HasDiagnostics` property was necessary in order to traverse nodes without forcibly instantiating their diagnostic lists.
- Added `GetAllDiagnostics` extension method for `RazorIRNode` to provide a way to retrieve all diagnostics that exist on and under a `RazorIRNode`.
- Updated `RazorIRNodeWriter` to display any diagnostics that exist on IR nodes.
- Internal `RazorIRNode`s do not have mutable `Diagnostics` because we don't currently add diagnostics to these elements.
- Added `DefaultIRLoweringPhaseTest` to validate that errors flow from syntax tree to IR document. Also added a missing test.
- Updated the `CSharpLoweringPhaseTest`s to properly validate that errors flow from IR document => csharp document. This resulted in movement of code to the ir lowering phase tests.
#1412
- Renamed many of our `RazorSourceDocument` abstractions to not include the word `Razor`.
- Added a `GetChecksum()` method to `RazorSourceDocument` to allow source documents to compute their own checksums.
- Re-generated codegen tests that did not normalize new lines. Ones that did re-generate newlines converted from stream => string => normalized string and then ran the Razor parser.
- Added tests to validate `GetChecksum` for all source document types.
- Removed unused `LegacySourceDocument`.
Ryan Nowak
Ryan Nowak
Ajay Bhargav Baaskaran
N. Taylor Mullen
Ajay Bhargav Baaskaran