AbstractSpellCheckCodeFixProvider depends on IDE completion options

[tmat]

The code fix provider reads CompletionOptions from Solution snapshot. These options are not configurable via .editorconfig, only in the IDE. Therefore this code fix provider will behave differently when executed from build vs IDE.

roslyn/src/Features/Core/Portable/SpellCheck/AbstractSpellCheckCodeFixProvider.cs

Lines 106 to 122 in f36574c

	private async Task CreateSpellCheckCodeIssueAsync(
	CodeFixContext context, SyntaxToken nameToken, bool isGeneric, CancellationToken cancellationToken)
	{
	var document = context.Document;
	var service = CompletionService.GetService(document);
	// Disable snippets and unimported types from ever appearing in the completion items.
	// - It's very unlikely the user would ever misspell a snippet, then use spell-checking to fix it,
	// then try to invoke the snippet.
	// - We believe spell-check should only compare what you have typed to what symbol would be offered here.
	var options = CompletionOptions.From(document.Project.Solution.Options, document.Project.Language) with
	{
	SnippetsBehavior = SnippetsRule.NeverInclude,
	ShowItemsFromUnimportedNamespaces = false,
	IsExpandedCompletion = false,
	TargetTypedCompletionFilter = false
	};

[tmat]

@CyrusNajmabadi What's the logic behind using completion items in spell checker? Should the spell checker use constant, non-configurable set of completion options rather then reading them from the solution options?

[CyrusNajmabadi]

@CyrusNajmabadi What's the logic behind using completion items in spell checker?

Basically, the idea is: completion already is the reverse side of this process. It informs us as to what names we already think are valid in this location (through all of our completion logic systems). So if you misspell something, we can just use completion to guess as to what they may have meant instead.

Should the spell checker use constant, non-configurable set of completion options rather then reading them from the solution options?

I think a constant set of options is entirely fine.

[tmat]

Sounds reasonable.

[tmat]

@sharwell

We do have other code fix providers that depend on IDE options, e.g. Add Import.
Do we explicitly distinguish between code fix providers that are expected to be only invoked from IDE and those we want to potentially invoke from dotnet-format?

[sharwell]

this code fix provider will behave differently when executed from build vs IDE.

Code fixes are only executed in the IDE.

Analyzers execute in both, but NuGet-installed analyzers are blocked from accessing the IDE definitions of options.

[CyrusNajmabadi]

Closing out as by design.