This changes splits the ObjectReaders and ObjectWriters into partial classes that are compiled differently depending on the presence of two conditional compilation symbols:
- JSONSERIALIZATION_PROJECTSYSTEM - When enabled, compiles serialization for various project system types, such as RazorProjectInfo.
- JSONSERIALIZATION_ENABLETAGHELPERCACHE - When enabled, compiles ObjectReader methods that will return a TagHelperDescriptor from TagHelperCache if its checksum is already known.
* Handle skipped trivia in the C# tokenizer
Reaction to https://github.com/dotnet/roslyn/pull/75724. Will need to update to a version of Roslyn with this change to be able to test.
* Account for included newline
* Update versions
* Report an error when encountering a `#` in skipped tokens, new tests/update baselines
* More baselines
* Add test example
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.12
into release/dev17.13.
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.12
- https://github.com/dotnet/razor/find/release/dev17.13
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.12-to-release/dev17.13
git reset --hard upstream/release/dev17.13
git merge upstream/release/dev17.12
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.12-to-release/dev17.13 --force
```
This is an automatically generated pull request from release/dev17.11
into release/dev17.12.
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.11
- https://github.com/dotnet/razor/find/release/dev17.12
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.11-to-release/dev17.12
git reset --hard upstream/release/dev17.12
git merge upstream/release/dev17.11
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.11-to-release/dev17.12 --force
```
This is an automatically generated pull request from release/dev17.10
into release/dev17.11.
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.10
- https://github.com/dotnet/razor/find/release/dev17.11
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.10-to-release/dev17.11
git reset --hard upstream/release/dev17.11
git merge upstream/release/dev17.10
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.10-to-release/dev17.11 --force
```
Microsoft.SourceBuild.Intermediate.arcade , Microsoft.DotNet.Arcade.Sdk
From Version 9.0.0-beta.24516.2 -> To Version 9.0.0-beta.24562.13
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Follow up to https://github.com/dotnet/razor/pull/11191 which caused RPS
regressions.
There were some edge-y things I papered over in that PR, assuming they
were unnecessary over-complications, but given the RPS regression I had
a closer look, and they could have caused re-compilation of closed
documents when only tag helpers changed, which would be new behaviour.
Not _entirely_ convinced the re-compilation is all unnecessary (if a
document used a Tag Helper that has only just been discovered, then its
code gen would legitimately change) but it's hard to justify when I
can't point to any tooling for the closed files that would actually
benefit from the extra work.
The key thing is not changing `DocumentCollectionVersion` when only
`ProjectWorkspaceState` changes. Not re-calculating import documents was
just a little extra amuse-bouche, and not caching the computed state
tracker is pure paranoia.
Fixes#9878
It turns out that this extension method isn't necessary. It's only used
by the legacy editor, which can just access
`IProjectSnaphshot.ProjectWorkspaceState.TagHelpers`. That property is
always implemented by any project snapshot that the legacy editor
encounters, namely `ProjectSnapshot` or `EphemeralProjectSnapshot`.
Since the named pipe support is intended to only be used by RZLS, this
change moves the support types into `MS.ANC.Razor.LanguageServer` and
organizes them in a `MS.ANC.Razor.LanguageServer.Hosting.NamedPipes`
namespace. In addition, I've moved a couple of `IServiceCollection`
extension methods into the `MS.ANC.Razor.LanguageServer.Hosting`
namespace to avoid opening up internals visible to access to the entire
`MS.ANC.Razor.LanguageServer.Extension` namespace, even if it's just to
RZLS. The goal of having `RestrictedInternalsVisibleTo` for the
`MS.ANC.Razor.LanguageServer.Hosting` namespace is to control the
exposed surface area of the language server. If something is needed by
VS or RZLS, strongly consider whether it should just be added to the
`Hosting` namespace to avoid unintentionally dependencies that might
need to be detangled later.
Note: Once this is merged, I'll submit a PR to update the code pointer
comment at
eb38986a52/src/razor/src/razorLanguageServerClient.ts (L228).
This change moves the necessary extension methods to the MS.ANC.Razor.LanguageServer.Hosting namespace to avoid needing to expose a larger namespace outside of the language server. RestrictedInternalsVisibleTo is a tool for controlling the implicit surface area of the language server, and we should add to that surface area judiciously.
Since INamesPipeProjectInfoDriver is a contract between MS.ANC.Razor.LanguageServer and RZLS, it doesn't need to live in Razor.Workspaces. Instead, it should live in the language server's Hosting namespace.
It turns out that this extension method isn't necessary. It's only used by the legacy editor, which can just access `IProjectSnaphshot.ProjectWorkspaceState.TagHelpers`. That property is always implemented by any project snapshot that the legacy editor encounters, namely `ProjectSnapshot` or `EphemeralProjectSnapshot`.
When first introduced there was an error in assumption of how histogram telemetry worked. This fixes this by correctly reporting a unique histogram even per lsp method name rather than the first one that comes in (which, as it turns out, was always initialize)
Also cleaned up the wording so it was a little easier to understand.
Razor side of implementing IRazorMappingService.
Adds a RazorEditorHelper that specifically is designed to handle complex edits in csharp files that are generated by razor. Handles adding, removing, renaming, and a mix of both for usings. The rest of edits are put exactly where they map to.
Preparation for ongoing work to hook up the Roslyn tokenizer and
https://github.com/dotnet/razor/issues/11182 I suppose.
There were three places that `UpdateProjectWorkspaceState` was called:
1. In `RazorProjectService`, just before calling
`UpdateProjectConfiguration`
2. In `ProjectWorkspaceStateGenerator`, where we will need to add a call
to `UpdateProjectConfiguration` in future, to wire up the tokenizer
3. In our LiveShare bits, in response to events from the above.
Previous attempts to plumb through more things for `RazorConfiguration`
resulted in RPS failures, that appeared to be simply more compilations
of closed files. This makes sense because we were adding another update,
which would have triggered another set of `ProjectChanged` events. I
thought it would make more sense to combine these two updates together,
so no matter which part of the project was being updated, there could be
a single `ProjectChanged` notification. This is that.
* Move completion resolve code to common layer
* Undo move of IProjectSnapshotManagerExtensions and MiscFilesHostProject per PR feedback
* Undo unnecessary changes in tests
* Refactor the code to remove usage of IProjectSnapshotManager
Dustin Campbell
David Wengier
Chris Sienkiewicz
dotnet-maestro[bot]
Fred Silberberg
dotnet bot
Jan Jones
Jan Jones
dotnet-maestro[bot]
Andrew Hall
Bill Wagner
Alex Gavrilov