This is a MEF service that can actively or passively track open ITextViews
and give us information about the Razor initialization state and eventing
when it changes.
The purpose of this is to act as a bridge between the VS mef world and the
roslyn world.
For now this doesn't do any passive tracking of Razor documents, it's only
on demand. That means it will only be initialized and used right now when
you are using the Razor developer tools. This is just to reduce our risk,
it's not ideal to ship code in VS that's doing something without anyone
looking at the result.
- Moved the type out of the Legacy namespace.
- Renamed the types method to `GetBinding` since `TagHelper` is now inferred.
- Updated test names to reflect new method/class name.
- Updated product code variables to reflect new naming (provider => binder).
#1289
- Added a `GetAttributeCompletions` API that's consistent with current Razor's editor expectations.
- Added unit tests to validate all code paths of the new `GetAttributeCompletions` method.
#1120
- This involved not using the `First()` method when reading the directives tokens.
- Added two tests to validate an empty directive token and a missed directive token for the `@namespace` directive.
#1268
- Found that our extensible directive string parsing system wasn't consistent with the rest of the extensible directive tokens. Basically, if there were malformed string tokens we'd consume them and pass them along to extensible directive passes. This was a big no-no because it means extensible directive passes weren't able to rely on tokens being passed to them being well-formed.
- Fixed up existing extensible directive tests that relied on output of string tokens.
#1247
- Added C# 7 test to validate questionable features work end-to-end.
- Had to add several explicit package references to let our VS specific packages work as expected.
#1046
- Made a targeted fix to PageDirective that stops it from crashing Visual Studio when its malformed.
- Added unit test to validate PageDirective didn't throw when attempting to determine if something was a page.
- Added an integration test to validate malformed page tags can make their way through the entire Razor pipeline and don't destroy the rest of the content.
#1247
- Prior to this change we'd try to substring a TagHelper directive with length 1 but our substring call would be for -1 (explosions).
- Added tests to validate that `@tagHelperPrefix`, `@removeTagHelper` and `@addTagHelper` all behave properly when they have malformed quotes.
#1242
- Prior to this TModel would be set to a potentially non-fully qualified name. This would cause errors in default MVC templates.
- Regenerated test files to reflect new TModel.
- Updated unit test to reflect new behavior.
#1222
- Prior to this if you had a `TagHelper` whos output hint was not in the final form of the completions we'd fall through into a schema check which resulted in a completion being added when it shouldn't. Example: `TagHelper` for `my-tr` that has an output hint of `tr` would end up getting added to the completion list under `body` because `my-tr` was not in the schema and would then be treated like the `environment` `TagHelper` (a new element).
- Added a test to validate that `TagHelper`s with output hints are cross referenced vs. existing completions and do not fall through to a schema check.
#1225
- We don't want tooling applying tag helper prefix to what we deem `TagHelper`s. Ultimately we should consume all the necessary data and do that work.
- Added two tests to validate that we're applying tag helper prefix to `TagHelper` element completions for catch-all's and non-catch-alls.
#1224
- Prior to this catch-alls were explicitly ignored not to populate the IntelliSense with an excess amount of `TagHelper`s. To maintain backwards compatible expectations this commit reverts that expectation.
- Scoped an existing test to only test its primary scenario.
- Added a new test to verify that catch-alls accurately apply to all completions (including dynamically added ones).
#1219
The problem is that @inject uses the type name, and @namespace can change
it. Setting an explicit order makes sure that these things happen in a
sensible sequence.
- Added a new `TagHelperCompletionService` which can be queried for information on what completion information should be provided.
- Added tests to validate the completion service's expectations.
- Fixed an issue where `TagHelper`s with output hints that did not exist in a passed in completion would never be highlighted as `TagHelper`'s; even when their primary targeting element was already in the element completion list.
#1181
This change adds support for @namespace, and introduces a set of
changes that are needed to support @namespace in the parser.
@namespace and @class have always been treated as reserved words by Razor,
with the intent that someday they would be allowed as directives.
This changes makes that possible.
You will still get an error about @namespace being a reserved word if you
don't have the directive.
- A `null` parent tag in all of our other API represents "any" parent tag, or in this case "root". Prior to this change we'd expect the caller to do their own verification of the parent and then assume all `TagHelperDescriptor`s are valid; this isn't sufficient because only our code base should have that knowledge.
#1188
- Prior to this change the `TagHelper` parsing would strip the opt-out character (`!`) from tag names that got passed to the TagHelper matching services. At design time this proved to be a problem because they have their own understanding of the HTML document and only pass us full tag names (names that include `!`). This changes the matching conventions to immediately return false if a tag name is seen to contain the `TagHelper` opt-out.
- Added two `DefaultTagHelperFactService` tests to verify that tag names with opt-out prefixes are denied `TagHelperDescriptor`s.
#1186
This change adds support for accepting a namespace name in extensible
directives. This will be needed for the @namespace directive.
Implemented new parsing and codegen for namespaces using nameof().
Also fixed any issue where we were not global::-qualifying object where it
was used in the design time code for tokens.
- Prior to this change default imports would get line pragmas generated for them because thye'd have a source location but no file path (they were a dynamic document).
- Re-generated C# files to reflect new line pragma changes.
#1110
- The lazy addition of namespaces gives the main document lowering phase an opportunity to add source location information which we then add after the main lowering.
- Re-generated csharp to capture addition of using statements that were previously overridden by defaults/imports.
#1174
- We were generating line pragmas for using directives but not line mappings. This resulted in 0 IntelliSense when written within the Razor editor.
- Regenerated test files to reflect new line mappings.
#1162
- At design time we weren't generating line mappings when a user would type `@` or `@(`. This results in no C# IntelliSense being provided to the user because the editor hasn't mapped any of Razor to the C# buffer.
- Modified the `DefaultIRLoweringPhase` to allow for marker symbols, these symbols .
- Re-generated test files to account for 0 length line mappings on empty expression nodes.
#1155
- At design time we weren't generating line mappings when a user would type `@` or `@(`. This results in no C# IntelliSense being provided to the user because the editor hasn't mapped any of Razor to the C# buffer.
- Updated the design time renderer and design time writer to account for empty expressions.
- Modified the `DefaultIRLoweringPhase` to set source locations on empty expression nodes.
- Re-generated test files to account for 0 length line mappings on empty expression nodes.
#1155
- 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.
Ryan Nowak
Ajay Bhargav Baaskaran
N. Taylor Mullen
Pranav K
Yves57
Ryan Brandenburg
Jass Bagga
Doug Bunting
Stefan Nikolei