Rework code action service #899
Merged
Conversation
This file contains 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
This change reworks how we compute code fixes and refactorings. Much of this is just basic refactoring and clean up, but there are substantial changes to to code fixes are computed. Now, we'll return code fixes when there are multiple diagnostics with overlapping spans. For example, consider this scenario:
```C#
class C
{
void M()
{
StringBuilder
}
}
```
There are three diagnostics at the position immediately following `StringBuilder`:
1. CS1001: Identifier expected
2. CS1002: ; expected
3. CS0246: The type or name 'StringBuilder' could not be found
The problem is that the first two diagnostics have a zero-width span immediately following `StringBuilder`, but the last diagnostic has the same span as `StringBuilder`. Previously, if the code action service was called with the line and column after `StringBuilder`, only the first two diagnostics would be considered for fixes because their spans are an exact match. However, it's the last diagnostic that we really want because that's the one for which the 'add import' code fix is triggered by. This change ensures that we'll consider all relevant diagnostics when computing code fixes.
DustinCampbell
added a commit
to DustinCampbell/vscode-csharp
that referenced
this pull request
Jun 28, 2017
Fixes dotnet#1605 When calling CodeActionProvider.provideCodeActions(...), VS Code passes the range of the word to the left of the editor caret if there's no selection. This ends up causing refactorings like Extract Method to be offered even when the user hasn't selected any code. Now, we'll check to see if there's actually a selection and use that instead of the range that's given. To fully fix this issue, I've made several changes in OmniSharp: OmniSharp/omnisharp-roslyn#899. Once that goes in, we'll need to update the version of OmniSharp used by C# for VS Code.
filipw
approved these changes
Jun 28, 2017
Yup, I'm hoping to look at that soon. |
|
And FWIW, if I add extension ordering, it'd be temporary. That's really an implementation detail that should be handled by a proper service from Roslyn. |
david-driscoll
approved these changes
Jun 28, 2017
| { | ||
| internal static class DictionaryExtensions | ||
| { | ||
| public static TValue GetOrAdd<TKey, TValue>(this IDictionary<TKey, TValue> dictionary, TKey key, Func<TKey, TValue> valueGetter) |
There was a problem hiding this comment.
someone add this to the BCL. 🔮
|
Thanks guys! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This change reworks how we compute code fixes and refactorings. Much of this is just basic refactoring and clean up, but there are substantial changes to to code fixes are computed. Now, we'll return code fixes when there are multiple diagnostics with overlapping spans. For example, consider this scenario:
There are three diagnostics at the position immediately following
StringBuilder:The problem is that the first two diagnostics have a zero-width span immediately following
StringBuilder, but the last diagnostic has the same span asStringBuilder. Previously, if the code action service was called with the line and column afterStringBuilder, only the first two diagnostics would be considered for fixes because their spans are an exact match. However, it's the last diagnostic that we really want because that's the one for which the 'add import' code fix is triggered by. This change ensures that we'll consider all relevant diagnostics when computing code fixes.