Since the end of last week, these tests have been failing. Seems like
something changed on the platform side, perhaps a default value of a
setting. Have started a thread with the editor team to see if we need to
do more.
* When @Inject is missing the member name, generate a syntactically valid c# identifier so we get intellisense
* Emit an empty section when there is no typename
* Add tests and update baselines
Because of a dare from @333fred, I'm currently on a crusade to remove
`ItemCollection` from the Razor Compiler completely. Previously, I
removed `ItemCollection` from `TagHelperDescriptorProviderContext`
(#10720). This time, I'm removing it from `CodeRenderingContext`.
It turns out that every `CodeRenderingContext` greedily creates an
`ItemCollection`, though there are only ever two things stored there:
1. A string to use for new lines in `CodeWriter`.
2. A string representing "suppress IDs", which is already specified in
`RazorCodeGenerationOptions`.
These two items were really present as a hook that compiler tests could
set. However, it's much easier and less wasteful to elevate both items
to `RazorCodeGenerationOptions` and make tests set the options directly.
I made a few other refactorings as part of this change:
- I merged several abstract base classes with their single default
concrete type:
- `CodeRenderingContext` and `DefaultCodeRenderingContext`
- `RazorCSharpDocument` and `DefaultRazorCSharpDocument`,
- `RazorCodeGenerationOptions` and `DefaultRazorCodeGenerationOptions`
- `RazorCodeGenerationOptionsBuilder` and
`DefaultRazorCodeGenerationOptionsBuilder`.
- Reworked `RazorCodeGenerationOptions` and introduced
`RazorCodeGenerationOptionsFlags` to track its boolean fields.
- Cleaned up `RazorCSharpDocument` and unified its collections on
`ImmutableArray<>` rather than `IReadOnlyList<>`.
- Enabled nullability annotations for several types.
- Used more pooled collections in `CodeRenderingContext`.
Note: I was careful with my commit history, and it should be clean
enough to review commit-by-commit if that's your preference.
Always felt like a huge potential bug farm. eg, if Html ended up not being first we'd have bugs, working out the Order property (which was weirdly backwards?) was a pain, and the entire formatting engine produces horrible results if the ordering changes anyway.
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
```
David Wengier
David Barbet
David Barbet
dotnet bot
Chris Sienkiewicz
dotnet-maestro[bot]
Dustin Campbell