Deletes CSharpIRToken to use the more general RazorIRToken class.
Rather than using the visitor to visit tokens, now writing a
CSharpExpresionIRNode is an 'atom', and will write its tokens itself.
Introducing ExtensionIRNode and an implementation of templates based on
the new feature set.
Now TemplateIRNode is-a ExtensionIRNode. It's implemented using just
extensibility and isn't part of the standard razor codegen. I'm adding it
to the RazorEngine so that it's still there by default.
I've also included a pattern for visitors to special case
ExtensionIRNode-derived classes that they know about. This requires a
little bit of boilerplate but makes it easy to traverse just the nodes you
care about while keeping the set of nodes open.
For now the general codegen feature still hasn't had a refactor, but this
opens things up for us to start finishing things like MVC's @inject
directive.
This is a new abstraction that represents the api surface available for
codegen to target. Every kind of document should have an associated
RuntimeTarget or just use the default.
To prevent breakage, our DocumentClassifierBase class will provide a
default API set to implementors (like MVC).
I haven't fundamentally changed how codegen is done yet, I've just hidden
it behind a new abstraction. The RuntimeTarget now is also responsible for
selecting between design time and runtime.
The bulk of the noise here is from splitting a lot of the codegen stuff
into its own files.
The issue here is that when a taghelper prefix is in use it will be
including in the HTML output, when it should be chopped off.
See the diff in the codegen for examples.
The IR lowering phase was attaching the 'tag helper fields' node to the
builder instead of to the top-level node (document). This meant that
things wouldn't be where we expect when the first tag helper occurrence is
inside a directive block (section).
Found this porting MVC to use the new Razor codebase.
We're close to hooking up new Razor to MVC. This is a set of enabling
'quick fix' changes to resolve some blockers to using Razor.Evolution in
the product.
Main issues:
- Types not public enough - anything in the .Legacy namespace is still
slated from 'improvement'
- Wrong references. We don't want .Workspaces in MVC, so moving the heavy
lifting of TagHelper discovery to CodeAnalysis.Razor.
This commit adds support to the TagHelperBinderSyntaxTreePass to interpret
@addTagHelper, @removeTagHelper, and @tagHelperPrefix.
I also ported all the original tests for this feature and updated them to
call new APIs.
The bulk of the changes here were updates to baseline tests that weren't
correctly using @addTagHelper
This change adds support for 'imports' - extra source files which contain
directives that can merged with 'main' source files. The purpose of course
is to support things like global usings or addTagHelpers, like
_ViewImports in MVC does today.
Instead of a one-off this is now a feature of the Razor langugage since
things like addTagHelper have an impact on the parsing behavior. Also,
having a standard imports concept keeps out feature creep, for instance
the 'global' usings we have today could really just be an import.
Imports allow single-line directives including the fundamental directives
like addTagHelper, using, and other friends. Code, content, and block
directives are not merged and will be ignored. We can consider making
these kinds of things warnings in the future.
This change defines stages for IR processing. The comments in RazorIRPass
really explain the details. I've also made the preliminary changes to the
stuff we've built so far to follow the new conventions.
This is building towards multitargeting for Razor, being able to target
both Razor Pages and Razor MVC Views from the same engine, being able to
target different codegen and methods from within the same engine.
- Added TabSize,IsIndentingWithTabs and NamespaceImports to the RazorParser options. These are replacements for the existing RazorEngineHost abstraction.
- Added RazorParserOptions consumption pattern to more than just the parsing phase.
- Added a ChecksumIRNode to ensure Debugging can work.
- Updated tests to to react to new Checksum and Namespace nodes in the IR tree.
- Removed existing type names used to track `@functions`, `@section` and `@inherits`.
- Updated parsing logic to reflect existing directive behaviors.
- Added additional IR and syntax tree pass in order to fulfill the default directive expectations.
- Updated tests to to expect new extensible directives parse structure.
#894
- Also modified the property name from `SourceLocation` => `SourceRange` to avoid ambiguity.
- Updated IR baselines
- Updated IR baseline infrastructure to conditionally render the document location.
#884
- Added conditional attribute test.
- Reacted to Html optimization pass in tests.
- Removed directive IR bits since they'll be handled by the extensible directive system.
#844
This is an API skeleton for the IR data model that we'll be using as a
spiritual continuation of the 'chunks' API. Currently missing a lot of
detail which will be filled in as needed.
Ajay Bhargav Baaskaran
Ryan Nowak
N. Taylor Mullen