* Add prelimianry support for extensions to Razor
This PR adds MSBuild insfrastructure to the SDK that can understand
concepts we need to expose to the project, code generator and runtime
like:
- Language version
- Configuration
- Extensions (plugins)
As an example of how this works, I've done the wireup for MVC. This will
now generate assembly attributes in your application that can act as a
source-of-truth for what should be included in runtime compilation, and
it's all based on the project-file. This means that it can be delivered
and configured by packages.
The next step here is to implement a loader for RazorProjectEngine based
on these primitives, and then use it in our CLI tools and MVC.
The next step after that is to expose it in VS and VS4Mac through the
project system.
(cherry picked from commit 5b28c06d64)
- Restructured RazorLanguageVersion to be a sealed concrete type to enable things like `RazorLanguageVersion.Latest`; it also allows us to make broader changes in the future. Also, in the future if we want to add support for overriding operators to enable greater than comparisons we can as well.
- Removed version validity checks because we restrict who can construct a `RazorLanguageVersion` now. This way we don't have to check for valid versions all throughout our code.
- Added a simple `ProjectExtensibilityConfiguration` => `RazorLanguageVersion` method in the `DefaultProjectExtensibilityConfigurationFactory` to temporarily enable letting the system operate on the `RazorLanguageVersion`. Eventually that entire class will change.
#1961
- Added a standalone brace smart indenter that listens to `ITextBuffer` changed events to determine when a brace completion event needs to be handled.
- Added methods to deal with getting document trackers from `ITextBuffer`s.
- Added a `BraceSmartIndenterTest` and `BraceSmartIndenterIntegrationTest` to verify all parts of the smart indenter.
- Moved private test infrastructure classes into their own files and expanded on their functionality to enable the brace completion smart indent scenarios.
#1538
- Created a new `Microsoft.VisualStudio.Editor.Razor` assembly to contain Visual Studio platform agnostic info.
- Added a new `Microsoft.VisualStudio.Editor.Razor.Test.Common` project to be the centerfold for all VisualStudio agnostic test pieces.
- Added a `Microsoft.VisualStudio.Editor.Razor.Test` project and pulled in LanguageService test files into the the Editor.Razor.Test project to correspond to their movement in the src project.
#1690
- Added APIs to retrieve an `ITextBuffer` from a `Document` and to retrieve a `RazorCodeDocument` from an `ITextBuffer`.
- The `RazorCodeDocument` from `ITextBuffer` API supports both the new and old Razor parsers so we can transition seamlessly between the two.
- Added logic in the `RazorDirectiveCompletionProvider` to consume descriptions from `DirectiveDescriptor`s. This is then surfaced via tooltips.
- Retrieved currently active `RazorCodeDocument` given a Roslyn buffer and harvested all directives to display in the completion list.
- Added unit tests to validate each new services functionality.
#291
- Added 1_X src project for multitargeting
- Added 1_X test project for multitargeting
- Added 1_X test MvcShim for multitargeting
- Make section directive generate the correct code the appropriate version
- Added another sln
We don't really want to ship what we have as a contract. As an emergency
measure we are making it into internal extension methods so we can have
a do-over in 2.1.
- 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
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.
- 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 `DirectiveUsage` to enable extensible directive authors to indicate how their directives should be used. Currently support `Unrestricted` (how section directives have always worked) and a file scoped singly occurring directive.
- Added directive parsing tests.
- Removed no longer used `BlockKindInternal` items.
#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
- Updated tests to validate expectations.
- Added two additional tests to validate extensible directives and built-in directives get start at line verification.
Nate McMaster
Ryan Nowak
N. Taylor Mullen
Ajay Bhargav Baaskaran
Ryan Brandenburg