dotnet/roslyn

Move to new file doesn't honor charset in .editorconfig

Open

#34,200 opened on Mar 17, 2019

View on GitHub
 (0 comments) (2 reactions) (0 assignees)C# (20,414 stars) (4,257 forks)batch import
Area-IDEBugFeature - Editor Confighelp wanted

Description

Version Used: 15.9.9

Steps to Reproduce:

  1. Have an .editorconfig with charset = utf-8
  2. Open an existing file (encoding irrelvant)
  3. Add a type to the file
  4. Apply "Move type to new file" refactoring

Expected Behavior:

The new file is stored in the encoding specified by .editorconfig (in this case UTF8, no BOM).

Actual Behavior:

The new file is stored in UTF8-BOM.

Contributor guide

Tech stack
csharp
Domain
backenddeveloper experience
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Basic C#Understanding of .editorconfigFamiliarity with Roslyn refactoring infrastructure
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
Investigate the 'Move type to new file' refactoring in the Roslyn codebase. Look for where the .editorconfig charset setting is read (likely in the EditorConfigService or related code). Then check how the new file encoding is determined in the refactoring. The issue states that the new file uses UTF8 BOM instead of UTF 8 without BOM. The fix should ensure the charset from .editorconfig is honored. Start by finding the relevant files in the Features or Workspace layer, such as the rename or move type services.