- 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
The new @namespace directive isn't sanitizing class and namespace names
when generating them. This means that a file-system-legal character like
'-' will show up in a class name, and that's not good.
Note that the old code paths (document classifiers) already had tests for
this and did it properly. It was only missing from @namespace.
- Instead of rendering a null assigning statement for a type token we now render a `default(TTypeToken)`. With this approach type tokens can be value types without creating a design time error.
- Re-generated baseline files to reflect new directive token code generation.
#1176
- Split line mapping validation into its own method.
- Prior to this we were calling the wrong method in our design time code generation integration tests within the Razor.Extensions test project.
- Re-generated line mapping baselines to conform with the cshtml files for Razor.extensions code generation integration tests.
#1351
This change adds an API for Tag Helper discovery.
I also got rid of the 'design time' flag for the provider as an
experimental change. We need to think through the consequences of this
before committing to it. Right now I've left those tests failing until we
can make a decision.
This change decouples VCTH discovery a bit more, but we're still not ready
to move that into a the MVC extensions assembly. For that we need the
ability to discover the MVC extensibility.
This change removes the default usings for 'System' and
'System.Threading.Tasks' and adds them to the MVC template engine.
This is preparation for removing this feature from the razor options, I
wanted to get all of the intentional diff out of the way.
- These tests validate that our extensible directives do not have code that explodes when an incomplete directive is encountered. This is typically the case when a user is in the midst of typing a directive at design time.
- Added an extensions test and a language test.
#1271
- 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
- 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 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
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.
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.
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