I couldn't originally test some code actions because they used the file
system, so I intended this PR to fix that by abstracting the file system
away. It is that, but I also found some more tests that we lacked
coverage for in cohosting, and since I find the cohosting tests to be
just so wonderful (not biased at all, obviously) I thought I'd be a bit
extra.
I deliberately didn't try to fix any of the code actions, but I think
they could probably all do with some nicer whitespace handling. Managed
to avoid the self-nerd-snipe this time though.
For a long while IDocumentSnapshot's FileKind, FilePath, and TargetPath properties have all been annotated as nullable. It turns out that the only reason for this was ImportDocumentSnapshot, which has been removed. So, we can now allow these properties to be correctly annotated as non-nullable,
This change removes several parameters from DocumentState.GenerateCodeDocumentAsync(...) and computes them internally. So, there's no longer a need to expose GetImportsAsync for GenerateCodeDocumetnAsync callers.
The comment explaining why this DocumentState method is internal seems to be out of date. It's currently only used within DocumentState, so this change removes the comment and makes it private.
This one might be a _little_ controversial in terms of how I wired the
`LanguageServerFeatureOptions` up through the `ProjectSnapshot`, but
it's somewhat similar to how it works in cohosting, with
`RemoteProjectSnapshot -> RemoteSolutionSnapshot ->
SolutionSnapshotManager -> LanguageServerFeatureOptions`.
Aside from that aspect of the specific implementation, which you're more
than welcome to critique and suggest an alternative to, the fundamental
change here is removing `LanguageServerFlags` and using
`LanguageServerFeatureOptions` directly. It seems that
`LanguageServerFlags` was intended to encapsulate the feature options
for the compiler, but since that time they are never actually used by
the compiler, and just ended up in a weird spot. They were "flags for
the language server", but were only ever initialized in VS. We we
essentially ended up with this unnecessary middle-man, that didn't
always exist. The `LanguageServerFeatureFlags` on the other hand are
always set in VS, VS Code, etc.
TL;DR: Now that all of the code for deciding whether to use runtime
compilation is entirely on the tooling side, it just makes sense to use
the tooling side options class directly.
These flags were explicitly not for the compiler, being not serialized, and hence don't really belong on RazorConfiguration.
They also were only ever set in the VS layer
Turns out the boolean parameter passed in here is read in exactly one
spot in our code, and that line of code is never hit in these tests
because they use mocks.
Yes, this is the equivalent of removing a `Thread.Sleep` that was put in
previously, but I'm taking it regardless :)
Even though component attributes look like HTML they map to generated
C#. In this case, Hover prefers C# over HTML and requests hover data
from Roslyn. This adds a test for that scenario.
Even though component attributes look like HTML they map to generated C#. In this case, Hover prefers C# over HTML and requests hover data from Roslyn. This adds a test for that scenario.
This is an automatically generated pull request from release/dev17.13
into main.
Once all conflicts are resolved and all the tests pass, you are free to
merge the pull request. 🐯
## Troubleshooting conflicts
### Identify authors of changes which introduced merge conflicts
Scroll to the bottom, then for each file containing conflicts copy its
path into the following searches:
- https://github.com/dotnet/razor/find/release/dev17.13
- https://github.com/dotnet/razor/find/main
Usually the most recent change to a file between the two branches is
considered to have introduced the conflicts, but sometimes it will be
necessary to look for the conflicting lines and check the blame in each
branch. Generally the author whose change introduced the conflicts
should pull down this PR, fix the conflicts locally, then push up a
commit resolving the conflicts.
### Resolve merge conflicts using your local repo
Sometimes merge conflicts may be present on GitHub but merging locally
will work without conflicts. This is due to differences between the
merge algorithm used in local git versus the one used by GitHub.
``` bash
git fetch --all
git checkout -t upstream/merges/release/dev17.13-to-main
git reset --hard upstream/main
git merge upstream/release/dev17.13
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.13-to-main --force
```
This is an automatically generated pull request from release/dev17.13
into main.
Once all conflicts are resolved and all the tests pass, you are free to
merge the pull request. 🐯
## Troubleshooting conflicts
### Identify authors of changes which introduced merge conflicts
Scroll to the bottom, then for each file containing conflicts copy its
path into the following searches:
- https://github.com/dotnet/razor/find/release/dev17.13
- https://github.com/dotnet/razor/find/main
Usually the most recent change to a file between the two branches is
considered to have introduced the conflicts, but sometimes it will be
necessary to look for the conflicting lines and check the blame in each
branch. Generally the author whose change introduced the conflicts
should pull down this PR, fix the conflicts locally, then push up a
commit resolving the conflicts.
### Resolve merge conflicts using your local repo
Sometimes merge conflicts may be present on GitHub but merging locally
will work without conflicts. This is due to differences between the
merge algorithm used in local git versus the one used by GitHub.
``` bash
git fetch --all
git checkout -t upstream/merges/release/dev17.13-to-main
git reset --hard upstream/main
git merge upstream/release/dev17.13
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.13-to-main --force
```
David Wengier
dotnet-maestro[bot]
Bill Wagner
Dustin Campbell
Pierson Lee (PIE)
Andrew Hall
Jan Jones
Alex Gavrilov
dotnet bot