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
```
Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.XliffTasks
From Version 9.0.0-beta.23577.2 -> To Version 9.0.0-beta.23578.2
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
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
```
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
```
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
```
* Add telemetry reporter dependency to the fallback project manager
* Make sure we never bring down project loading if there is a problem with the fallback bits
* Only support fallback documents that are in the project cone
* Make things more efficient, and cross platform
* Validate target paths
* Fix tests linux and mac (even though the fallback project manager never runs on linux or mac)
The initial IFaultExceptionHandler MEF construction was no longer working due to refactoring. This changes it to no longer use MEF and just report directly.
Also update the ExceptionStrategy to ISerializable, since that will set the InnerException property if the other end of the connection is the same. This will make error reporting for us contain remote stacks instead of our own. If that's not the case, we still report as much as we can.
Anyone looking for more information on jsonrpc errors can look at microsoft/vs-streamjsonrpc@main/doc/exceptions.md
Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.XliffTasks
From Version 9.0.0-beta.23572.2 -> To Version 9.0.0-beta.23577.2
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
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
```
A couple days ago, @ToddGrun pointed me to some [Prism
data](https://prism.vsdata.io/failure/?query=ch%3Drelease%20r%3D17.8&eventType=allocation&failureType=dualdirection&failureHash=30151e5e-e8aa-2e4c-a22f-106e4d7f8e6c)
indicating that there's a lot of allocation due to
`SyntaxListBuilder.Grow(...)`. I dug in and made several changes that
should improve things.
1. `SyntaxListBuilder` is now pooled everywhere it's used. The builders
contain single arrays that can grow to a maximum of 512 entries. That
should eliminate the allocations that we're seeing in
`SyntaxListBuilder.Grow(...)`.
2. I introduced a `ChildNodesHelper` struct to avoid boxing
`ChildSyntaxList` to an `IReadOnlyList<SyntaxNode>` just to call
`Skip(1).ToList()` in a special case.
3. Updated code to avoid boxing `ImmutableArray<SyntaxTree>` to
`IReadOnlyList<SyntaxTree>` for imports.
4. Added helpers to avoid calling params arrays.
There are some unrelated clean up changes, so it might be useful to
review a commit at a time if those changes get in the way:
1. I've annotated `SyntaxNode`, `SyntaxList`, `SyntaxList<T>`,
`SyntaxListBuilder` and `SyntaxListBuilder<T>` for nullability.
2. I renamed the misspelled API, `RazorEnginePhaseBase.OnIntialized()`
to `RazorEnginePhaseBase.OnInitialized()`.
5. I refactored similar code in `FormattingVisitor` and
`ClassifiedSpanVisitor` to be shared. These algorithms were pretty much
identical, and I decided to refactor rather than update the code in both
places.
Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.XliffTasks
From Version 9.0.0-beta.23570.1 -> To Version 9.0.0-beta.23572.2
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Phil Allen
David Wengier
dotnet bot
David Barbet
David Barbet
dotnet-maestro[bot]
Jan Jones
David Wengier
Andrew Hall
Rikki Gibson
Dustin Campbell