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.
- Literal directive tokens acted as a way for a user to provide markup bits to be required when parsing a directive.
- Removed source implementations.
- Removed tests validating the feature.
#969
- Roslyn swapped the way they performed dotless commit insertions. They went from:
date => date. => DateTime. to
date => date. => date => DateTime => DateTime.
The problem with the new approach is that date => DateTime would be rejected and therefore force the editor to reparse and reclassify any dots as HTML giving improper IntelliSense.
- Updated Razor implicit expression edit handling to allow identifier => identifier replacements as long as the identifiers didn't result in keyword or directives.
- Added tests to verify the scenarios impacted.
This is a replacement for RazorError, is conceptually equivalent with
Diagnostic from Roslyn.
The next PR will start exposing this through our public API rather than
the legacy type.
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.
- Hardcoded `ViewComponent` discovery.
- Hardcoded `ViewComponentTagHelperDescriptor` creation.
- Added test to validate that ViewComponents are discovered and transitioned into TagHelpers properly.
- Avoided adding a reference to MVC to prevent circular references. This resulted in custom marker attributes to represent `ViewComponent`s. Also made a lot of use of `ViewComponent` conventions (ending in "ViewComponent").
#932
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.
- Ported the existing descriptor factory tests and fixed issues with the current implementation.
- Ported documentation tests with the exception of the localization variants.
- Updated the DefaultTagHelperResolver to filter TagHelper types based on accessibility.
- Added DefaultTagHelperResolver tests.
#851
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
- 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
This change adds a basic framework for doing baselined integration tests.
This is very similar to what we do elsewhere with generated files and
tests that read them from resources.
What's here now is the support to do this kind of baselining with IR in a
pretty readable serialization format.
This is a building block and the intent is that we'd do something similar
in the future for syntax nodes and C# source.
Looking at the code of the tests in particular, we'll also build the
ability to capture the documents at key points (such as before/after a
targeted phase) and then verify them in the same manner.
This change adds a way to actually configure the RazorEngine to use
extensible directives (previously buried behind legacy API). As part of
this feature adds the RazorParserOptions class to encapsulate anything
else that becomes a parser options (ahem taghelpers).
Now we have a pattern for this when we get there.
Options are propagated as part of the RazorSyntaxTree for
testability/sanity and this was actually responsible for the bulk of the
changes.
Also added some extension methods for adding directives to the
IRazorEngineBuilder and an end to end integration test.
This change adds a phase which runs IR passes. Design and code are almost
exactly the same as the existing SyntaxTree phase. However all of this is
public because the IR is public API.
- Based generic directive implementation off of descriptors.
- Added parsing logic to consume descriptors and parse content that's expected.
- Added parsing errors to automagically detect unexpected directive pieces.
- Updated visitor implementations to understand the directive bits.
- Added a builder abstraction to easily create descriptors. Had to maintain the ability to manually construct a descriptor to enable convenient serialization/deserialization.
- Added tests/comparers to verify correctness of parsing.
#853
- Add an `HtmlNodeOptimizationPass` that does all of the `RazorSyntaxTreeRewriting` that legacy used to achieve outside of `TagHelper`s.
- Add tests for `HtmlNodeOptimizationPass` to verify it's executing appropriate bits.
#849
- 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
- Added a TagHelperFeature to hold TagHelper specific pieces that can be replaced.
- Built a syntax tree pass that applies the ported TagHelper bits.
- Updated tests that expected different RazorEngine defaults.
- Added new tests to verify binder pass.
- Modified how tests are run to reflect our new test infrastructure.
- Added TagHelper assertion bits.
- Moved all classes to the Evolution.Legacy namespace.
- Copied Test.Sources bits to the Evolution.Test project.
#845
- Removed the `CreateReader` API in favor of a `CopyTo`, `Length`, `[index]` and `Encoding`.
- Updated existing APIs to react to the change.
- Added tests.
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.
- Prior to this change any query for ownership within a TagHelper would never succeed.
- TagHelpers structure can be influenced greatly by changes to the tags start/end body; therefore, only allowed modifications to TagHelper attribute values to avoid complexity and enable the more widespread scenario of a user typing C# code in an attribute value.
- Updated existing tests to reflect the new edit handlers that were added to TagHelper attributes.
- Added partial parsing tests to verify partial parses succeed/fail when expected.
#792
- Several classes are legacy and left over from many changes in the Razor code base. This changeset removes those classes.
- Also moved several corresponding test cases
#778
- #760
- using a `NullHtmlEncoder` improves `TagHelperContent.IsEmptyOrWhiteSpace` semantics
- e.g. a tab is still a tab after encoding
- also avoids `NotImplementedException`
- implement `Write(char)` for char-by-char `IHtmlContent` corner case
- Removed `Minimized` from `TagHelperAttribute` and replaced it with `HtmlAttributeValueStyle`.
- Removed `AddMinimizedTagHelperAttribute` method from `TagHelperExecutionContext` since we always provide a `HtmlAttributeValueStyle` now.
- Stopped manually escaping double quotes because we now know how an attribute was originally written.
- Updated tests to account for new attribute format (from kvp).
#705
- Today `TagHelperContent`s always allocate their underlying buffer even though they typically only ever have a single entry. Added a field to enable us to only allocate the backing buffer when we absolutely need to.
- Removed `IsEmpty` from `TagHelperContent` since it was not used in any of our `TagHelper`s for simplification. Changed `IsWhiteSpace` naming to be `IsEmptyOrWhiteSpace` since it can be used to indicate either state.
- Updated tests.
#621
- Previously we'd do `executionContext.Output.Content = await executionContext.Output.GetChildContentAsync()`. The problem with this approach is that it returned a `Task<TagHelperContent>` which could not be optimized when building in release.
- Added test to validate `SetOutputContentAsync` does the appropriate thing.
#721
- `TagHelperOutput` and `TagHelperContext` lifetimes now mach `TagHelperExecutionContext`s. This means once a set of `TagHelper`s have run on a tag the `TagHelperOutput`/`TagHelperContext` will be re-used.
- Added tests to validate the various `Reset`/`Reinitialize` methods behaved correctly.
- Updated codegen to no longer set `TagHelperExecutionContext.Output`.
#719
- was missing when writing out full name of an `enum` value
- was missing in one case when writing out `TagHelperAttribute` type name
nit: updated `CSharpTagHelperFieldDeclarationVisitor.WritePrivateField()` to always include the prefix
- no change in generated code but centralizes the prefix addition and reduces intermediate `string`s
- After discussion offline to maintain consistency we decided to also remove `CodeBase` fallback in the net451 scenario. This will keep CoreCLR and net451 scenarios more consistent.
- Removed `CodeBase` validation tests.
- Added `GetAssemblyLocation` extensibility point to enable proper testing of the `TagHelperDesignTimeDescriptorFactory`.
#709
- Added the ability for users to opt into CSS `TagHelper` selectors in their required attributes by surrounding the value with `[` and `]`. Added operators `^`, `$` and `=`.
- Added tests to cover code paths used when determining CSS selectors.
#684
This change implements the new API for flattening content in Razor.
Also, some optimizations to avoid allocations on paths where we need
to encode HTML attribute values.
- aspnet/Coherence-Signed#187
- remove `<RootNamespace>` settings but maintain other unique aspects e.g. `<DnxInvisibleContent ... />`
- in a few cases, standardize on VS version `14.0` and not something more specific
- Hoist `TagHelperAttribute` creation into `private static readonly` fields to avoid allocations on every request. With the recent `TagHelperAttribute` change that made them immutable we can now pre-allocate them without worry of them being modified.
- Added two extra class configuration pieces to enable pre-allocation.
- Updated test files to showcase new pre-allocations.
#600
- Currently the `TagHelperScopeManager` creates a new `TagHelperExecutionContext` per `TagHelper` on a given page. With this change the max number of `TagHelperExecutionContext`s per page is the number of nested levels that exist.
- Added two tests validating that specific pieces of `TagHelperExecutionContext` are updated as expected.
#674
- Changed the variable used to render templates (`HelperResult`s) so they can be used inside of sections.
- Updated section test file to showcase nested scenario. Also Regenerated existing test files.
#572
- Not all `TagHelper`s have unbound HTML attributes or any attributes at all. A great example of this is MVC's input `TagHelper` which usually takes the format of `<input asp-for="..." />`. By lazily initializing we don't build extra attribute lists where not needed.
- Moved `TagHelperContext` and `TagHelperOutput` creation to CreateX methods on `TagHelperExecutionContext`.
#604
- Remove a lot of the ugly generic work done in `TagHelperAttributeList`/`ReadOnlyTagHelperAttributeList`.
- Removed error cases where we'd check on addition of `TagHelperAttribute`s that their `name` was not `null`. This was due to the pre-existing `string` indexer for `TagHelperAttributeList`. It no longer sets `TagHelperAttribute`s directly, instead it's `[key] = value` (instead of `[key] = new TagHelperAttribute(...))`.
- Updated tests to account for new immutability/string indexer format.
- Removed copy ctor from `TagHelperAttribute` since its immutability kills the value.
- Changed `ReadOnlyTagHelperAttributeList` to inherit from `ReadOnlyCollection`
#604
This change 'flattens' a TagHelperOutput when writing it out to an
HtmlTextWriter. This is a beneficial perf change because more often than
not the thing being written to is a ViewBuffer in Razor, which uses pooled
memory. This allows us to 'join' islands of pooled ViewBuffer memory back
into the main buffer instead of keeping them wrapped up in a
TagHelperOutput or TagHelperContent.
- #643 part 1
- change is viral and requires an update to `RazorPage.StartTagHelperWritingScope()`
- memoize `GetChildContentAsync()` per-encoder
- update generation tests to match and to test new behaviour
- note `HtmlEncoder`s used elsewhere e.g. in other `RazorPage` instances are unaffected
Add `NullHtmlEncoder`
Nits:
- generally clean up affected doc comments and make them more consistent
- remove unused `using`s in files I had open
Changing to IReadOnlyList since we always want to support indexing.
Replacing ToArray() with non-linq when needed, and with a static
EmptyArray when not needed.
Eliminates 50mb of list copies.
- Roslyn currently has an issue where too large of strings result in out of memory exceptions at compile time. To combat this I broke down literal strings into 1024 length pieces each resulting in their own `WriteLiteral`/`WriteLiteralTo` calls. The 1024 number corresponds directly with MVCs response string buffer.
- Added tests to validate large string rendering.
#614
- Prior to this change we'd hit the disk every time we'd create a `TagHelperDesignTimeDescriptor` to locate an assemblies XML files.
- Did not want to tie the XML cache to a static member in-case a user updates their XML information between parses. Therefore, changed `TagHelperDescriptorFactory` and `TagHelperDesignTimeDescriptorFactory` to no longer be static.
- Put the same `TagHeleprDescriptorFactory` extensibility point as we had for its counterpart `TagHelperTypeResolver` to stay consistent. This involved making `CreateDescriptors` virtual and allowing it to be provided in the `TagHelperDescriptorResolver` constructor.
#630
- Updated existing tests and added a new case to understand `@section {....` scenarios.
- Instead of trying to guess 1 character prior to EOF decided to log error on opening brace since we know its position. Updated error to account for change in location.
#625
- This allows users to write `TagHelperOutput` directly to an `IHtmlContent` accepting `TextWriter`.
- This also enables us to inspect backing fields for all of the various contents to lazily initialize them.
#358
This change significantly reduces the amount of string and List<ISymbol>
allocations that occur during compilation by changing the way
LiteralChunks are combined.
This is a low impact fix that addresses the performance issue, the design
issues that caused it still exist.
The problem here lies in what Razor fundamentally does - it parses HTML/C#
into tokens, and then combines them back into 'chunks' a representation
friendly to code generation. When presenting with a large block of static
HTML, Razor parses it into individual HTML tokens, and then tries to join
them in back into a single chunk for rendering. Due to details of Razor's
representation of chunks/tokens, the process of combining literals is too
expensive.
Mainly, what's done here is to not try to combine instances of
LiteralChunk. The process of merging them is too expensive and requires
lots of interm List<ISymbol> and string allocations.
Instead we produce a new 'chunk' ParentLiteralChunk, which doesn't do so
much up-front computing. Various pieces of the code that deal with
LiteralChunk need to be updated to deal with ParentLiteralChunk also,
which is the bulk of the changes here.
Note that we still have the potential for LOH allocations to occur during
codegen, but it's likely to occur O(1) for each large block of HTML
instead of O(N) as it did in the old code.
- Updated .cshtml files to not provide quotes for the various `TagHelper` directives.
- Updated `TagHelper` directive parsing tests. This also involved removing several tests that expected errors which no longer occur since we don't have to ensure quotes are balanced.
- Updated line mappings which significantly changed due to us no longer generating line pragmas at design time for `TagHelper` directives.
#561
- Template attributes should be of type `Func<TextWriter, Task>`. We weren't generating an `async` lambda for attributes prior to this change resulting in a compilation failure when used at runtime and the inability to `@await` code (unless a user returns some sort of `Task`).
- Updated code generation files to reflect the new code generation behavior.
#594
Doug Bunting
Ryan Nowak
N. Taylor Mullen
Ajay Bhargav Baaskaran
Pranav K
Nate McMaster
BrennanConroy
Nate McMaster
Jass Bagga
Crystal Qian
jacalvar
mnltejaswini
Pavel Krymets
ryanbrandenburg
David Fowler
Victor Hurdugaci
John Luo
Caleb Nelton
hexelium
Kiran Challa