- 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
instead of methods
More polish to the tag helper descriptor builders.
- Expose underlying builders as getter only list
- Added AsDictionary() extension method to BoundAttributeDescriptorBuilder
- Expose diagnostics as RazorDiagnosticCollection
- Got rid of Require** prefix in TagMatchingRuleBuilder
- Workaround issue aspnet/Razor#1492 by copying the test descriptor
extensions
This makes it possible to use another 'kind' of tag helpers, which isn't
possible today.
This also further decouples the tag helper api surface from the default
implementation.
VCTH now have their own 'kind'.
Also improved generation of display names and error messages where it
was coupled to the type name.
- Updated integration code gen and IR bits to reflect new directive usage.
- Updated existing unit tests that happened to test directives in code blocks to now test what happens when they exist at the document level. Being inside of a code block is now invalid and we have separate tests for that scenario.
#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 `DirectiveTokenEditHandler` to enable IntelliSense for invalid namespace tokens.
- Added tests to verify new `DirectiveTokenEditHandler`.
- Updated test expectations for `DirectiveTokenEditHandler`.
#1393
- Updated our `QualifiedIdentifier` to properly parse invalid namespaces. This is more consistent with how the rest of the system works; we consume tokens until we determine if we're in an invalid or valid state. If invalid, we log an error and put back all invalid tokens for the parser to treat as non-directive tokens.
- Added unit tests to validate our extensible directive system can handle malformed namespace tokens at EOF and inline.
- Added a code gen test for Razor.Extensions to prove we've fixed the underlying issue for our `@namespace` directive that crashed VS.
#1393
The new @namespace directive isn't sanitizing class and namespace names
when generating them. This means that a file-system-legal character like
'-' will show up in a class name, and that's not good.
Note that the old code paths (document classifiers) already had tests for
this and did it properly. It was only missing from @namespace.
- Instead of rendering a null assigning statement for a type token we now render a `default(TTypeToken)`. With this approach type tokens can be value types without creating a design time error.
- Re-generated baseline files to reflect new directive token code generation.
#1176
- Split line mapping validation into its own method.
- Prior to this we were calling the wrong method in our design time code generation integration tests within the Razor.Extensions test project.
- Re-generated line mapping baselines to conform with the cshtml files for Razor.extensions code generation integration tests.
#1351
This change adds an API for Tag Helper discovery.
I also got rid of the 'design time' flag for the provider as an
experimental change. We need to think through the consequences of this
before committing to it. Right now I've left those tests failing until we
can make a decision.
This change decouples VCTH discovery a bit more, but we're still not ready
to move that into a the MVC extensions assembly. For that we need the
ability to discover the MVC extensibility.
Ryan Nowak
N. Taylor Mullen
Ajay Bhargav Baaskaran
Pranav K
Ryan Brandenburg
Nate McMaster
Mike Harder
Nate McMaster