* 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.
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
```
* Moving RazorFormattingService to common layer
* Cleanup
* Switch Razor LSP server code to use RazorFormattingService from common layer
* Removing HTML formatting from common layer (for now)
It requires services not easily available and will require extra work. For now leaving it in LSP server layer. Current need for the formatting service in cohosting is for OnAutoInsert which doesn't need HTML formatting.
* Move AdhocServices, AdhoWorkspaceServices to common layer
* Cleanup moved resources
* Basic implementations for remote formatting classes
* Removing hardcoded option value
* Cleanup per CR suggestions
* Cleanup doc-comments
This PR is a classic self-nerd-snipe, and resolves this comment:
https://github.com/dotnet/razor/pull/10750#discussion_r1719087058
Also inadvertently found a slight "bug" with the existing go to def code
in cohosting. Bug is in quotes because the actual user behaviour
probably was identical in 99% of cases.
* Added new tests for the specific regressed scenario.
* Allow `@@` sequences. Fixes https://github.com/dotnet/sdk/issues/42730 for now. When we move to the new lexer, these will once again be disallowed; attempting to use runtime compilation will necessitate using the native lexer.
* Fixup legacy test baselines
In light of "should we get rid of document context" convo this morning, figured this made sense to do (and I needed _something_ on IDocumentSnapshot in order to actually make this whole idea work)
This was a subtle future bug, that we would have hit when we removed the C# syntax tree bits in future. By checking for Razor GTD first we weren't deferring to Roslyn for plain attributes (ie, the case without `@bind-` in the tests) which means at best we do some extra unnecessary work, and at worst we could lose features for things Roslyn supports but we don't.
I did not intend to find this bug when I started. Sorry for missing it in the PR Dustin. The key is that `ignoreAttributes` should have been `true` when porting over the code, and changing that would have made the test fail in your branch.
Fixes#10631
Here's support for Go to Definition under co-hosting. Tests are still
incoming (and I'll add them before merging), but I wanted to get this
out for review to see if there's anything I missed or should implement
differently.
Chris Sienkiewicz
Dustin Campbell
dotnet bot
David Wengier
Alex Gavrilov
Phil Allen
Fred Silberberg
Jared Parsons