- Use pooled `ImmutableArray<RazorDiagnostic>.Builder` internally
- Don't request pooled builder until first error is added
- Make ErrorSink disposable to return builder to pool
- Add GetErrorsAndClear() method to returns an `ImmutableArray<RazorDiagnostic>` and clears out the sink.
- Add 'ParserContext.PushNewErrorScope(...)` to handle the temporary ErrorSinks used by CSharpCodeParser
A few integration tests to investigate, but the guts are here.
I'm _slightly_ worried this might cause us to recompile files more
often, but there is also the chance this fixes a bunch of bugs by
recompiling files more often :)
Commit-at-a-time review is highly recommended, as there are lots of flow
on effects of API changes
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.
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
```
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.
Dustin Campbell
Chris Sienkiewicz
dotnet-maestro[bot]
David Wengier
dotnet bot
David Barbet
David Barbet