- Prior to this if all instances of `TagHelper`s in an assembly had editor browsable never we'd log an error saying that no TagHelpers were found for that assembly. Until we can evaluate a better fix for this issue I've removed the logic that logs those errors and its corresponding tests/resources.
#1145
- Add API to enable the editor to query information on the state of `TagHelper`s within a Razor document.
- Refactored methods from `TagHelperDescriptorProvider` to be in a `TagHelperDescriptorConventions` class so the language service could use them.
- Added `DefaultTagHelperFactService` tests.
#1120
This is a new API for tooling to call to get a RazorTemplateEngine that's
initialized correctly. For now this is hardcoded to use MVC's conventions.
This is also a very temporary design to get us past the next wave of
changes.
We'll eventually want to change this to an ILanguageService, but this will
require some new plumbing in the editor, so let's defer that for another
day.
(cherry picked from commit a73b5f58a8713076433d24668b99705388b6d6b3)
The RazorParserOptions were only configurable via an internal interface
and an extension method on the builder. This isn't suitable for VS because
we need to be able to update the configuration while the editor is open,
without creating a new engine.
- When `RequiredAttributeDescriptor`s are displayed in an editor their display name differs based on their name comparison mode. If their name comparison mode happens to be a prefix match then we need to append three dots to indicate that it's a required prefix for an attribute.
- Added a new descriptor builder test to validate `DisplayName` is created correctly.
#1119
- Normalize paths to be absolute and to also use forward slashes.
- Updated our `EnsureValidPath` method to be `NormalizeAndEnsureValidPath`.
- Added tests to validate new `NormalizeAndEnsureValidPath`.
- Updated existing tests to react to `NormalizeAndEnsureValidPath` correctly.
#1106
This is a code dump from tooling -> Razor
This service will exist to answer questions about syntax trees for the
editor. Right now I'm just moving in the code in the simplest way
possible. Tests + cleanup to follow.
- Removed all design time descriptors and put their API surface into their corresponding descriptor. Part of removing the design time API surface was removing the tracking of `<Remarks>`, it wasn't used so there's on need to track it until we need it.
- Removed the Type requirement from `TagHelperDescriptor`. With this separation we'll be able to have abstract `TagHelper`s that aren't based on a class implementation.
- Removed Prefix from the `TagHelperDescriptor` API surface. It was a legacy requirement based on how the Razor parser was put together. We can work around this now.
- Stripped correlation information from the immediate `TagHelperDescriptor` API surface. Instead this information is now tracked in `TagMatchingRule`s. This change means that you will not have multiple `TagHelperDescriptor`s per `TagHelper`; instead it's all tracked in a single descriptor. A side effect of this change was the transformation of `IsIndexer` => 3 new properties.
- Renamed many descriptor types and property names.
- Added builder APIs to construct TagHelpers since they're inherently immutable in their API surface.
- Added `ITagHelperDescriptorBuilder` to represent `TagHelper`s that are built from an `ITagHelper` implementing class. It re-introduces the `TypeName` association of a `TagHelper`.
- Added `ITagHelperBoundAttributeDescriptorBuilder` to represent that an attribute was associated with a property.
- Added validation methods to the descriptor builders to enable consumers to validate the current state of the builder and add diagnostics as necessary.
- Moved descriptors away from RazorError.
- Updated the various comparers to understand the descriptors new API.
- Added a new `RazorDiagnosticFactory` abstraction to handle `RazorDiagnostic`s and their corresponding errors/ids etc. This new API should allow for easy addition of new `RazorDiagnostic` errors.
- Updated the `DefaultTagHelperDescriptorFactory` to construct `TagHelperDescriptor`s using the new builder APIs and in the new descriptor format (1 descriptor per type).
- Updated `ViewComponentTagHelperDescriptorFactory` to construct `TagHelperDescriptor`s with the builder API.
- With both factory implementations code was duplicated because the ViewComponent work will be moving outside of Razor once we have the proper hooks.
- Updated `TagHelper` binding bits to capture a binding result in order to query which rules appy to a given tag name.
Addressed feedback
- Update tests to react to new `TagHelperDescriptor` API.
- Remove case sensitive comparers and some cleanup
- Added TagHelperDescriptorJsonConverter, RazorDiagnosticJsonConverter and added serialization tests
We still need this for now. Both constructors call the non-obsolete
constructor on the base class.
Will remove this once ServiceHub starts calling the new constructor.
VS has gone RTM so, updating to the RTM versions of those dependencies.
Roslyn does not publish our shim packages on NuGet.org, so updating those
to a non-ancient version for projects that use 2.0.0. The projects that
use 1.3.x are staying put for now.
The code change is dealing with something that was obsoleted.
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.
Pranav K
N. Taylor Mullen
Ryan Brandenburg
Ajay Bhargav Baaskaran
Jass Bagga
Ryan Nowak
Doug Bunting
Stefan Nikolei
Nate McMaster
Yves57