gopls의 대화형 리팩터링

gopls에 여러 단계의 대화창으로 사용자 입력을 받은 뒤 코드를 변환하는 대화형 리팩터링이 도입됨. gopls v0.24.0과 VS Code 공식 Go 확장 v0.56.0에서 사용할 수 있음 LSP 확장 제안은 언어 서버가 편집기별 맞춤 구현 없이 사용자에게 필요한 정보를 묻도록 함. Dart 팀과 협력해 모든 프로그래밍 언어와 편집기를 위한 개방형 표준으로 설계했으며, 아직 제안 단계임 구조체 태그 편집은 태그 종류와 명명 규칙을 선택하거나 특정 태그만 삭제할 수 있고, 인터페이스 구현은 동적 심벌 검색과 타입 인수 입력을 거쳐 메서드 스텁을 생성함 선언 이동은 대상 파일을 선택하면 의존 선언을 함께 옮기고 참조와 import를 정리함. 파일과 패키지 간 이동이 가능한 구현은 있지만, 정식 제공은 향후 gopls 릴리스로 예정됨 향후에는 함수 시그니처 변경, 이름 충돌 해결, 프로파일링 옵션을 지정하는 테스트/벤치마크 실행 등으로 대화형 기능을 확장할 계획임 LSP에 사용자 입력이 필요한 이유 LSP(Language Server Protocol) 는 언어별 기능과 특정 편집기를 분리하는 개방형 표준임 VS Code, Neovim, Emacs 같은 편집기와 gopls 같은 언어 서버가 JSON-RPC로 통신하며 자동 완성, 호버 문서, 진단, 코드 액션을 제공함 기존 LSP의 코드 변환 대부분은 매개변수 없는 함수처럼 작동함. 사용자가 실행하면 서버가 곧바로 수정 내용을 계산함 심벌 이름 변경만 새 이름을 입력받는 예외이며, 이를 위해 전용 PrepareRename RPC가 필요했음 언어 서버는 커서 위치와 구문 트리만으로 의도를 추론해야 했으므로, 정보가 부족하면 획일적인 기본값을 적용하거나 기능 자체를 제공하지 못했음 어떤 구조체 태그와 명명 규칙을 쓸지, 어떤 인터페이스를 구현할지, 선언을 어느 파일로 옮길지는 문맥만으로 알 수 없음 기존 “Add struct tags”는 항상 camelCase 형식의 json 태그를 생성했음 한계는 gopls의 코드 수정 능력이 아니라, LSP에 사용자 입력을 요청할 수단이 없다는 데 있었음 일부 언어 확장은 편집기별 맞춤 대화창으로 우회했지만, 최소한의 클라이언트 코드로 LSP를 따르는 Neovim과 Emacs 등은 혜택을 받지 못했음 이런 우회 방식은 언어 기능과 편집기를 분리해 서버 개선이 모든 클라이언트에 적용되도록 한다는 LSP의 목적에도 맞지 않음 언어와 편...