Reenable the 'use auto property' lightbulb.#5743
Closed
CyrusNajmabadi wants to merge 7 commits intodotnet:masterfrom
Closed
Reenable the 'use auto property' lightbulb.#5743CyrusNajmabadi wants to merge 7 commits intodotnet:masterfrom
CyrusNajmabadi wants to merge 7 commits intodotnet:masterfrom
Conversation
A couple of changes have been made here. We no longer implement this feature as a 'compilation end' analyzer. Instead, it's a 'symbol analyzer'. This should ideally mean that the results it produces are available much quicker since we don't have to wait for the compiltion analysis to end. Previously this was a compilation analyzer because we wanted to also analyze all usages to see if switching to an auto-prop would break things. Now we eagerly detect that you can convert to an auto prop, but we defer the conflict check to when you try to apply the feature (like we do for "inline temp").
Conflicts: src/Compilers/Core/Portable/DiagnosticAnalyzer/AnalyzerDriver.CompilationData.cs
Member
|
What's the difference between this and #5722? Should that be closed in favor of this? |
Contributor
Author
|
They're different approaches (one tries to avoid creating/calling into a semantic model). We're trying to find out why we're seeing so many perf problems. @mavasani @KevinH-MS and I are looking into things, and we're using these different PRs to investigate. |
Conflicts: src/EditorFeatures/VisualBasic/UseAutoProperty/VisualBasicUseAutoPropertyAnalyzer.vb
Contributor
Author
|
retest this please |
Contributor
Author
|
retest prtest/lin/dbg/unit32 please |
Contributor
Author
|
retest prtest/lin/dbg/unit32 please |
6 tasks
jjonescz
pushed a commit
to jjonescz/roslyn
that referenced
this pull request
Apr 28, 2026
* Fix HTML completion race when typing too quickly
- There was a race when typing too quickly our synchronization mechanism would try and reduce the work that was done to cancel pre-existing requests. So in the scenario when you were to type `<tr` what would happen is that 3 completion requests would fire:
1. Triggered completion for `<`
2. Typing completion for `t`
3. Typing completion for `r`
Now when we sped things up we were able to process requests in parallel which meant that we could handle simultaneous requests for `<`, `t` and `r` all at the same time; however, this in turn results in an interesting behavior where if we ask for completion at `r` while `<` and `t` are still active our synchronization mechanism would aggressively cancel the older requests. For completion this is catastrohpic because it would result in a 0 length completion list because HTML does not respect completion requests beyond trigger characters and the beginning of the word.
- To fix this issue I added a new mechanism for synchronization which takes a flag `rejectOnNewerParallelRequest` which states do not reject a synchronization request aggressively if this flag is `true`. Now this doesn't mean the requests never get rejected. If there's a batched document update or document close / open this will still reject the document; it just means that on the requesting of synchronization that older completion requests are not rejected eagerly.
- Added tests to our projection and synchronization stack to account for this
- Ensured that these changes are not breaking changes so marked some bits as virtual.
### Before
### After
Fixes dotnet#5743
* Update src/Razor/src/Microsoft.VisualStudio.LanguageServer.ContainedLanguage/LSPDocumentSynchronizer.cs
Co-authored-by: Allison Chou <allichou@microsoft.com>
* Fix newer tests.
Co-authored-by: Allison Chou <allichou@microsoft.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A couple of changes have been made here. We no longer implement this feature as a
'compilation end' analyzer. Instead, it's a 'symbol analyzer'. This should ideally
mean that the results it produces are available much quicker since we don't have to
wait for the compiltion analysis to end.
Previously this was a compilation analyzer because we wanted to also analyze all
usages to see if switching to an auto-prop would break things. Now we eagerly
detect that you can convert to an auto prop, but we defer the conflict check
to when you try to apply the feature (like we do for "inline temp").