JSON.NET is no longer used by the majority of Razor product code. The
only components that use NewtonSoft.Json are LiveShare, benchmarks, and
the testing infrastructure. So, I've moved the JSON serialization
support code into a shared project that is linked into the appropriate
places, rather than compiled into `ProjectEngineHost`.
* Check line position validity before trying to resolve it as source position
* Fix character position check. We do get requests for position at the very end of the line, e.g. position 0 on an empty line, so we need to have stringly "greater than" for character position check.
* Missed $ in front of string that was meant to be interpolated
* CR feedback, duplicate code removal, correcting unit tests
* Adding Debug.Fail to improve issue visibility
* Update src/Razor/src/Microsoft.AspNetCore.Razor.LanguageServer/Extensions/PositionExtensions.cs
CR feedback
Co-authored-by: David Wengier <david.wengier@microsoft.com>
---------
Co-authored-by: David Wengier <david.wengier@microsoft.com>
First part of https://github.com/dotnet/razor/issues/9519
Razor side of https://github.com/dotnet/roslyn/pull/70819
This PR consumes the new Cohost server from Roslyn, and when enabled,
moves DocumentColor requests from being handled by our existing Razor
Language Server, to instead be handled by the new server. There is
currently no sharing of project system data or anything like that yet. A
few TODOs for follow ups, ~can't be merged, and indeed won't build,
until a Roslyn package is available etc. but~ it's reviewable while we
keep working, and more important its shippable in its "off" state.
~Ignore the last commit, obviously won't be merged :)~
While working to rationalize the various MEF and other DI containers in
the code base, I found that there was a dependency within `ProjectState`
and `DocumentState` on Roslyn workspace services. Really, only
`ProjectState` used the Roslyn `HostWorkspaceServices`, and it only used
it for a single service. So, the dependency can be broken by just
passing that service directly into `ProjectState`.
In addition, I've cleaned up some nullability annotations. Here's a
summary of the nullability changes and changes to invariants:
* `ProjectState` is now annotated for nullability. While doing this, I
decide to make it an invariant that `ProjectState` can never hold a null
`ProjectWorkspaceState`. Instead, if not provided a
`ProjectWorkspaceState`, it'll be created with
`ProjectWorkspaceState.Default`.
* `IProjectSnapshot.Configuration` and
`IProjectSnapshot.ProjectWorkspaceState` are now non-nullable.
* `RazorProjectInfo.Configuration` and
`RazorProjectInfo.ProjectWorkspaceState` are now non-nullable.
While adding nullability annotations to ProjectState, I decided to make
the ProjectState.ProjectWorkspaceState property non-nullable. It turns
out that a newly created ProjectState *might* have a null
ProjectWorkspaceState. It did not appear to me that this was useful,
so I added the invariant that a ProjectState will *always* have
a non-null ProjectWorkspaceState. If none is provided when a
ProjectState is created it'll get the ProjectWorkspaceState.Default
instance.
This is an automatically generated pull request from release/dev17.9
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.9
- 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.9-to-main
git reset --hard upstream/main
git merge upstream/release/dev17.9
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.9-to-main --force
```
This is an automatically generated pull request from release/dev17.9
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.9
- 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.9-to-main
git reset --hard upstream/main
git merge upstream/release/dev17.9
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.9-to-main --force
```
This is an automatically generated pull request from release/dev17.8
into release/dev17.9.
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.8
- https://github.com/dotnet/razor/find/release/dev17.9
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.8-to-release/dev17.9
git reset --hard upstream/release/dev17.9
git merge upstream/release/dev17.8
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.8-to-release/dev17.9 --force
```
Phil Allen
Dustin Campbell
David Wengier
dotnet bot
David Barbet
Andrew Hall
Alex Gavrilov
dotnet-maestro[bot]
Jared Parsons
David Wengier