- Added ability to understand valid inserts, deletes and replacements for the `@functions` directive (and any other directive that uses our extensible code block bits).
- Added unit tests.
- Updated existing tests.
- Found an issue when completing some C# items the auto-completions would impact the underlying snapshot after we'd captured the change. Fixed this by forcing a reparse when we detect that our understanding of the latest snapshot and the actual latest snapshot diverge.
#2408
- Allow identical `@using` directives in the primary document. This means that if a user types `@using System` twice in the primary document (i.e. `Index.cshtml`) then we'll generate that using statement twice; this enables proper C# IntelliSense to light up on both using statements and allows auto-completion to work because there's no more magical distinction logic for Razor code that is in the current document.
- Prior to this change if you had two identical using statements in the same document one would be in no-mans land mapped to nothing (not C#, not HTML) and the other would be mapped to C#; the second a user differentiated the two statements (i.e. adding a `.`) we'd distinctify the using statements resulting in an invalid completion.
- This PR has an end-user impact where they will now receive the normal C# warning about having duplicate using. I treated this prior behavior more as a bug because we threw away the first using directive instance which impacted editing and in general was a silly thing to correct for the user.
- Added new integration test showing how using directives are not de-duplicated in the primary document.
#1255
- This is part of a fix for #1255 - this change enables signature help in implicit expressions by improving the partial parsing. We're now smart enough about the contents of an implicit expression and attempt to balance parenthesis to determine if we should not full parse.
#1255
- We need to pre-emptively generate line pragmas to handle C# scenarios which are session based. For instance, if a C# completion session starts at a location without a pragma they capture the origination point; at which point if a user keeps typing we generate a line pragma drastically changing where the copmletion started resulting in a broken C# completion experience.
- Updated test files to reflect new behavior.
#2299
We want to have a way to specify the taghelper descriptors and imports to use while
processing a specific document.
- Added an overload to Process and ProcessDesignTime to take in a list
TagHelperDescriptors and a list of imports
- Added the corresponding CreateCodeDocumentCore overload
- Added GetTagHelpers and SetTagHelpers extension methods for
CodeDocument
- Added the necessary plumbing to use the taghelpers from the
CodeDocument when available and fallback logic.
- Added DocumentImportsTracker and updated background code generation
logic to use the new overload
- Added/updated tests
This change will allow someone extending Razor to use generic type
parameters in generated classes.
There's no user-level extensibility provided here yet, as in there is no
language support for adding type parameters.
* Merging changes (from dev branch; doing manually to squash them really)of HTML Parser to be aware of HTML Comments so TagHelpers don't complain about comments as content.
- For older version of Razor the HTML comments will be complained about by TahHelperRewriter
- RazorParserFeatureFlags tests now ensure that AllowHtmlCommentsInTagHelpers is true in 2.1 version and false in older versions
- Added extra test for IsHtmlCommentAhead to make sure Razor code transition is allowed in comment tag
- Moved the unallowed html comment ending to a static array.
- Existent imports are imports that have content that contribute to the processing of a Razor document. Prior to this we had a legacy expectation that code documents had empty markers in them for all of their import locations. This proved troublesome when cross-referencing files that had file paths and were supposed to be existent but weren't in metadata. Now that we have a project engine with a de-coupled import feature we can rely on the import feature for finding all locations of important files and then strip out any non-existent items.
- Restructured RazorLanguageVersion to be a sealed concrete type to enable things like `RazorLanguageVersion.Latest`; it also allows us to make broader changes in the future. Also, in the future if we want to add support for overriding operators to enable greater than comparisons we can as well.
- Removed version validity checks because we restrict who can construct a `RazorLanguageVersion` now. This way we don't have to check for valid versions all throughout our code.
- Added a simple `ProjectExtensibilityConfiguration` => `RazorLanguageVersion` method in the `DefaultProjectExtensibilityConfigurationFactory` to temporarily enable letting the system operate on the `RazorLanguageVersion`. Eventually that entire class will change.
#1961
- Part of caching length required the `Span`'s `ReplaceWith` method to propagate its changes to its parent so that it can propogate the change to invalidate all parent length caches.
- Added Span and Block tests to validate the interaction of caching.
#1927
This uses a feature of KoreBuild which will select PackageReference
versions based on a lineup file. This helps unify versions between repos
and helps us ensure we are consistent across multiple components.