Fixes a bug with preview formatting for FAR.
So when we ask the Roslyn API to classify C# for us, it will only
classify the actual C# tokens. We are responsible for filling in the
gaps and whitespace.
The bug is that the following text would have all of its whitespace
removed in the VS FAR preview window.
```
@{ var foo = "Hello, world!"; }
```
Would look like:
```
@{varfoo="Hello, world!";}
```
This fixes the issue and makes it look like what one would expect.
We had a bug where were not returning the correct span for highlighting.
Fixed this.
Also we have a problem here, we're using types in our tests that are
coming from Roslyn - however we're not getting IVT for our test
assemblies. So some additional pain is required.
This change implements version tracking the inputs and outputs of
generated code.
Version tracking is still best-effort - meaning that in some cases a
perfect system could avoid doing more work. However, since we base the
versions off of all of the inputs, we now that the guarantee that code
generation operations that happen 'out of order' will always result in
the newer inputs generating the newer outputs.
Fixes: https://github.com/aspnet/Razor/issues/2650
This change adds mock ups of the interfaces that we've been designing as
part of Razor FAR as well as the implementations. This isn't wired up to
anything yet in this PR, but the basic functionality here is stable
enough for us to stabilize and review.
For now we have the interface definitions in the Razor codebase until a
build of Roslyn is available with these definitions + IVT for us to use
them.
This builds support for tracking the effect of changes to imports on
other documents, and completes our model for being able to keep
generated code up to date.
Addresses a blocking issue for FAR of types when used in user-code in a
directive. The FAR infrastructure is skipping over the directive code
because it's mapped to `#hidden`. As you can see in the code, the token
provided by the user is already included in the projection mappings.
I think we didn't do this before because we didn't expect this code to
need line numbers - it's not really debuggable, and design-time codegen
doesn't happen when you build the project.
I think it's OK for now that we don't line-map (or include) directives
based on view imports. If you trigger FAR on an `@inject ...` in an
import for instance, you'll find the reference for the view import file.
That seems pretty good, and the only cases I can really imagine it being
broken would be for go-to-definition (within a Razor view). Lets revisit
in the future based on feedback.
- Prior to this project changes would trigger re-parses which would then be thrown away because source versions were identical.
- Added test to verify new SetOutput behavior.
aspnet/Razor.VSCode#184
The Blazor test infrastructure made a copy of the code in Razor and then
added some more features. This change backports the features needed for
the style of test we're using in Blazor.
I updated the MVC integration tests to use the new style, but I think
there's limited value in trying to rev all of the old tests.
One feature in particular that I removed from the old infrastructure was
the automatic inference of imports based on the file system. This
feature was wierd and doesn't parallel how these features work in
actuality. It's easy and more natural to test imports in new style
tests.
Loading multiple versions of a task assembly result results in MSBuild on .NET Core to fail.
Addressing this by moving the tasks in to the Sdk and renaming it. This should avoid
immediate issues for a 2.1 and 2.2 project co-existing and future proofs 2.2 and later.
Fixes https://github.com/aspnet/Razor/issues/2553
- Prior to this we had a `BackgroundDocumentGenerator` that would constantly be updating generated code containers. With this changes we've changed the details in how a `GeneratedCodeContainer` can be mutated. It can now be touched from any thread and is updated when an underlying `DocumentSnapshot` has available content. However, if a generated output comes through that's older then the last seen output we no-op.
- Removed `BackgroundDocumentGenerator` SetOutput logic.
- Updated tests to react to new behavior of `GetGeneratedOutputAsync`.
- Added new test to verify getting generated output results in the setting of the host documents output.
- The issue was that the `executeChildContentAsync` call was stopping the invocation of the `_endTagHelperWritingScope`. Therefore, we'd never finish the TagHelper content scope and all following content would be ignored.
- Added two tests to validate the new functionality.
#2561
* Auto generate CSharp syntax tree nodes
- Auto generated syntax nodes, visitors and factories
- Renamed RazorComment to RazorCommentLiteral to avoid a conflict
- Modified the Visit() contract
- Added new SyntaxKinds
- Regenerated baselines
* Updated the tokenizer and parser to operate on SyntaxTokens directly
- The tokenizer and parser now operates directly on SyntaxTokens (Green)
- The SyntaxToken(Red) is now created when the Span is built with the correct parent and position
- All other passes that run after the parsing is complete(TagHelperRewriter etc) will operate on the Red tokens.
- There is now only one type for all SyntaxTokens. They are differentiated by their SyntaxKind.
- Added equivalence checking for tokens
- Updated test code to react
- Regenerated baselines
Ajay Bhargav Baaskaran
Pranav K
Ajay Bhargav Baaskaran
Ryan Nowak
N. Taylor Mullen
Nate McMaster