- Updated existing singly occurring tests that verified that the directives must occur prior to any content to be theories that tested the joint "file scoped" behavior of the usage.
- Added tests that validate `FileScopedMultipleOccurring` can have duplicate directives without erroring.
#1377
- Updated integration code gen and IR bits to reflect new directive usage.
- Updated existing unit tests that happened to test directives in code blocks to now test what happens when they exist at the document level. Being inside of a code block is now invalid and we have separate tests for that scenario.
#1376
- Added `DirectiveUsage` to enable extensible directive authors to indicate how their directives should be used. Currently support `Unrestricted` (how section directives have always worked) and a file scoped singly occurring directive.
- Added directive parsing tests.
- Removed no longer used `BlockKindInternal` items.
#1376
- Added error case that enforces whitespace in between directive tokens.
- Upon encountering invalid directive tokens/states we bail out of parsing and log an appropriate error.
- Raised directive parse errors to the IR layer. This is slightly hacky given the parsers limitations; we swap out the error sink temporarily to capture all directive parser errors and then shove the errors collected onto the directives chunk generator.
- Added a `MalformedDiretiveIRNode` and corresponding pass to represent directives that are in an invalid state. Chose to not take the path of using the default `DirectiveIRNode.Diagnostics` member to enable users who are extending directives to only ever have to work with "valid" directives. If they want to work with malformed directives they can search the IR document for their malformed counterpart and handle it separately.
- Updated existing test expectations
- Removed some existing tests that were no longer valid (we don't call into user code if a directive is malformed).
#1173
- Added a `DirectiveTokenEditHandler` to enable IntelliSense for invalid namespace tokens.
- Added tests to verify new `DirectiveTokenEditHandler`.
- Updated test expectations for `DirectiveTokenEditHandler`.
#1393
- Updated our `QualifiedIdentifier` to properly parse invalid namespaces. This is more consistent with how the rest of the system works; we consume tokens until we determine if we're in an invalid or valid state. If invalid, we log an error and put back all invalid tokens for the parser to treat as non-directive tokens.
- Added unit tests to validate our extensible directive system can handle malformed namespace tokens at EOF and inline.
- Added a code gen test for Razor.Extensions to prove we've fixed the underlying issue for our `@namespace` directive that crashed VS.
#1393
- Updated tests to validate expectations.
- Added two additional tests to validate extensible directives and built-in directives get start at line verification.
- Without a directive string token having a `SpanKind.Code` it cannot have any sort of C# coloring associated with it.
- Updated tests to reflect new `SpanKind` expectations.
#1269
Created internal + public versions of
- BlockKind
- SpanKind
- AcceptedCharacters
That way these types are only exposed through the VS apis and not
through the runtime API surface.
Also deleted RazorEditorParser. Yep. It's going to take significant work
to just port it to the language services assembly. Let's reevaluate this
when we get closer to the next foundational update.
- 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
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.
Ajay Bhargav Baaskaran
Ryan Nowak
N. Taylor Mullen