Noticed in the logs that we were double-compiling files, and it was
causing issues in my "self versioned documents" branch. Separated out of
that to make it easier to review.
RCA is because we now share a project manager across VS and LSP server,
so we get real project information much sooner than before, which beats
file watchers etc.
This pull request is completely within shared code, but none of it is
exercised by anything but tests. I've extracted them from another branch
containing a much larger compiler change to avoid muddying that change.
This is an automatically generated pull request from release/dev17.12
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.12
- 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.12-to-main
git reset --hard upstream/main
git merge upstream/release/dev17.12
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.12-to-main --force
```
Because the sort performed by Enumerable.Order(...) and Enumerable.OrderBy(...) is stable, we need to do the same in the OrderAsArray* extension methods. This requires a pretty substantial change to compare indices in addition to values.
This is an automatically generated pull request from release/dev17.12
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.12
- 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.12-to-main
git reset --hard upstream/main
git merge upstream/release/dev17.12
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.12-to-main --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
```
* upstream/release/dev17.11:
Upgrade System.Security.Cryptography.Xml to avoid CG alerts.
Update System.Formats.Asn1 to address CG alert.
Manually reference Microsoft.IO.Redist 6.0.1 where needed to fix CG alerts.
Upgrade testing analyzers to address CG alert.
Update version of system.security.cryptography.xml in use in 17.10 (#10525)
This is an automatically generated pull request from release/dev17.11
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.11
- 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.11-to-main
git reset --hard upstream/main
git merge upstream/release/dev17.11
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.11-to-main --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
```
Every `TagHelperDescriptorProviderContext` creates an `ItemCollection`
to hold onto, at most, two objects: a `Compilation` and a target
`ISymbol`. This is enormously wasteful because an `ItemCollection`
internally creates a `ConcurrentDictionary<object, object>`. So, I've
changed `TagHelperDescriptorProviderContext` to just hold onto a
compilation and a target symbol and avoid the `ItemCollection`
altogether.
I recommend reviewing commit-by-commit.
Also, I bumped into a long standing compiler bug in
`EventHandlerTagHelperDescriptorProvider` that was recently filed by a
customer: https://github.com/dotnet/razor/issues/10497. I opted to stay
on target and not fix this issue, but I made it painfully obvious where
the fix would go. 😄
Dustin Campbell
David Wengier
Jan Jones
dotnet bot
Fredric Silberberg
Jared Parsons