This will log to the VS activity log any time we fail to discovery
taghelpers due to an exception. There's no real user experience around
this... if someone is having an issue we can ask them to send us the log
or post the relevant portion.
The issue here is that the OOP host doesn't yet have support for
documentation, it will just return null. Fixing this code to look for the
documentation after we get the descriptors back into VS.
I tested this and confirmed that it works with TagHelpers in dlls + xml
file documenation as well as TagHelpers compiled in the project itself.
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.
This IR node will be part of the new token model for IR. It will be used
by all nodes that contain user content. Going forward, tokens will be the
thing that contains text and produces line mappings.
This commit just introduces the class.
- Decided to not expose the resolutions errors in the Razor extension. If we feel that it's good debug information we can add it later.
- Added a `TagHelperResolutionResult` type to Razor.Workspaces so it can be used in the language and remote service.
#1014
We need the visitor to allow control over whether to recurse or not into
something. This change makes the old ParserVisitor class behave much more
like the newer IR Walkers.
We need this for the tokens refactor because IR lowering will not be just
a trivial visitor anymore in the future.
This change fixes a bug where DefaultRazorIRLoweringPhase is too
aggressive in merging HTML spans. You can hit the bug by delimiting two
html spans with a metacode character like:
<foo>@{ <bar/> }</foo>
The lowering phase will combine these HTML nodes, which is invalid as they
don't have contiguous spans.
The change here is to merge spans only when they both have an invalid
location or are contiguous.
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.
- Added DirectiveRemovalIRPass
- Added IRazorDocumentClassifierPhase, IRazorDirectiveClassifierPhase and
IRazorIROptimizationPhase
- Added all the related passes and default implementations
- Refactored DefaultDirectiveIRPass to do the right thing
- Execute method in IR passes now return void
- Added tests for the new phases
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
Ryan Nowak
Pranav K
Ajay Bhargav Baaskaran
N. Taylor Mullen
Nate McMaster