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.
This change does deduplication of taghelpers during the binding/rewriting
phase. This is needed when a taghelper has multiple sets of html
attributes that are required (behaves like an OR). This is used lots in
MVC.
The old codebase used to do this in the codegen phase, but it seems
beneficial to do as early as possible.
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.
Also adds the source document to the RazorSyntaxTree and does some cleanup
related to this. This lets us verify which tree goes to which document and
that seems important.
Added basic tests to verify that parsing happens, though it's not being
used for anything right now.
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.
This change ensures that spans are contiguous and that all source is part
of a span. This means that a character can't be 'lost' and not a member of
any span.
And guess what? We have a bug like that. So now a few tests are skipped
due to that bug.
Also made some changes to tests that construct invalid spans or spans
without correct locations as their expected input. This allows us to add
the above verification to all parser tests.
- Added a common csharp rendering phase base to put shared assets of runtime and design time code gen.
- Added a new `DesignTimeIRPass` to setup the IR bits to provide accurate intellisense.
- Added a `CodeGenerationIntegrationTest` and moved the RuntimeCodeGenerationTests into it. This way we can re-use the cshtml files and it makes searching/running the tests easy..
- Updated how line mappings are calculated for some nodes.
#848
- Previously we'd special case `@section` at code generation time; now we transform the directive into an IR node.
- Changed the expectations of `DefineSection` to not take in a section writer. It's now expected to modify what `Write`, `WriteLiteral` etc. write to when inside of the lambda. This is done today in TagHelpers via `StartTagHelperWritingScope`.
- Updated baseline files to reflect new `DefineSection` expectations.
- Updated IR tests since we no longer leave around `DirectiveIRNode`s.
#901
- Source ranges currently aren't normalized when they're input into the system. Due to how we serialize pieces of the code this breaks cross plat because of newline differences.
- This is a temporary work around to get the build passing cross plat.
- If needed, a phase/feature can always retrieve the syntax tree to lookup whether the parse tree was made in a "design time" fashion.
- Future DesignTime / Runtime specific bits will be added to their corresponding `AddRuntimeDefaults`/`AddDesignTimeDefaults` methods.
- 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
- Prior to this the platform that the newlines were escaped on would be the platform the baselines would pass on.
- Updated baselines to reflect new newline escaping.
#888
Ajay Bhargav Baaskaran
Ryan Nowak
Nate McMaster
BrennanConroy
N. Taylor Mullen
Pranav K
Nate McMaster