@ToddGrun shared a couple PerfView stacks with me where the Razor
compiler was allocating `List<SyntaxToken>` instances in the tokenizer.
To remove those allocation, this change replaces `List<SyntaxToken>s`
throughout the parsers and tokenizer, and uses
`PooledArrayBuilder<SyntaxToken>` instead. In addition, I removed a
couple of `Concat` calls and replaced them with pooled `StringBuilders`.
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1995012
From reading the docs on a few things, it seems the use of the attribute
is still in flux, and the team will notify partners when we should
migrate, so going to leave that for now.
@toddgrun pointed me to a fair amount of string allocation due
`ProjectKey.From(Project)` being called repeatedly on a hot path. To
address this, I've added `ProjectKey.Matches(Project)`, which simply
compares the current key's `Id` with the project's intermediate output
path. This uses a new
`FilePathNormalizer.AreDirectoryPathsEquivalent(...)` helper to avoid
allocating a new string.
@toddgrun pointed me to a fair amount of string allocation due `ProjectKey.From(Project)` being called repeatedly on a hot path. To address this, I've added `ProjectKey.Matches(Project)`, which simply compares the current key's `Id` with the project's intermediate output path. This uses a new `FilePathNormalizer.AreDirectoryPathsEquivalent(...)` helper to avoid allocating a new string.
This is an automatically generated pull request from release/dev17.10
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.10
- 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.10-to-main
git reset --hard upstream/main
git merge upstream/release/dev17.10
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.10-to-main --force
```
This is an automatically generated pull request from release/dev17.9
into release/dev17.10.
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/release/dev17.10
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-release/dev17.10
git reset --hard upstream/release/dev17.10
git merge upstream/release/dev17.9
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.9-to-release/dev17.10 --force
```
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
Part of https://github.com/dotnet/razor/issues/9519
This PR feels like the last month of my life, with most of that time
simply fighting ServiceHub.
This adds a new endpoint for the cohosting server to support semantic
tokens. It's the first endpoint in the server. (Almost) the only thing
it does is immediately call our to the OOP process to do the actual
work. Logic is mainly provided by the same service that the existing
semantic tokens endpoint uses, but for a small piece of functionality
that is plugged in, via MEF, to call Roslyn via a new C# API
(https://github.com/dotnet/roslyn/pull/72495) instead of via LSP.
Currently the syntax tree is computed on the fly in OOP, and the
document Roslyn is asked about is the one that the LSP server creates
via IDynamicFile. In future this will change to get the real source
generated document, and data from the source generator for the tree etc.
Reviewing commit-at-a-time is probably best. There are still a bunch of
TODOs, some hard-coded bits, and some hacky bits, but I wanted to ensure
this was actually reviewable and not too big.
Worth nothing this won't build until the Roslyn PR mentioned above is
merged, and a new package is available to update to.
One of the items in https://github.com/dotnet/razor/issues/10103
Part of https://github.com/dotnet/razor/issues/9519
Rather than move telemetry down into the service, I decided to leave it
in the endpoint, and C# specific service, so we can track separate
telemetry from existing LSP, to make it easier to report on. In theory
this is unnecessary because we already would know the status of A/B
flights in the telemetry data, but that doesn't allow for manually
switching the flag. If people feel strongly about not using different
properties, I'm fine to change. Perhaps all of our telemetry should
automatically log cohosting and fuse status as properties?
With this setting, the runtime config will require 8.0.1 to be set. This
can cause issues for those without the latest patch installed. Fixes
https://github.com/dotnet/razor/issues/10130
Now the runsettings look like
```json
{
"runtimeOptions": {
"tfm": "net8.0",
"rollForward": "LatestMajor",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0"
},
"configProperties": {
"System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization": false
}
}
}
```
Andrew Hall (METAL)
dotnet-maestro[bot]
David Wengier
dotnet bot
Dustin Campbell
Jan Jones
Rich Lander