안정화 요청

참고: 이 페이지는 언어 기능의 안정화를 다룹니다. 라이브러리 기능의 안정화에 대해서는 라이브러리 기능 안정화하기를 참조하십시오.

불안정 기능이 충분히 테스트되었고 남은 우려 사항이 없다면 누구든지 그 기능의 안정화를 추진할 수 있습니다. 다만 해당 기능을 작업해 온 사람들을 참여시키는 것이 바람직합니다. 다음 단계를 따르십시오:

필요한 경우 RFC 작성하기

해당 기능이 언어 실험의 일부였다면, lang 팀은 일반적으로 안정화에 앞서 RFC를 먼저 승인하기를 원합니다.

문서 PR

해당 기능은 src/doc/unstable-book에 있는 Unstable Book에 문서화되어 있을 수 있습니다. 기능 게이트에 대한 페이지가 있다면 제거하십시오. 그 문서에서 유용한 부분은 다른 곳에 통합하십시오.

문서 업데이트가 필요할 수 있는 곳은 다음과 같습니다:

The Reference: 반드시 빠짐없이 상세하게 업데이트해야 하며, 안정화가 병합되기 전에 lang-docs 팀의 구성원이 해당 PR을 리뷰하고 승인해야 합니다.
The Book: 필요에 따라 업데이트합니다. 확실하지 않다면 이 저장소에 이슈를 열어 주십시오. 그곳에서 논의할 수 있습니다.
표준 라이브러리 문서: 필요에 따라 업데이트합니다. 언어 기능은 대개 이것이 필요하지 않지만, ?가 언어에 추가되었을 때처럼 관용적인 예제의 작성 방식을 바꾸는 기능이라면 라이브러리 문서에서 이러한 예제를 업데이트하는 것이 중요합니다. 표준 라이브러리의 키워드 문서와 ABI 문서도 검토하십시오. 이 문서들은 언어 변경에 따라 업데이트가 필요한 경우가 있습니다.
Rust by Example: 필요에 따라 업데이트합니다.

위에서 언급한 저장소들에 대해 이 새 기능과 관련된 문서를 업데이트하는 PR을 준비하십시오. 이 저장소들의 메인테이너는 전체 안정화 과정이 완료될 때까지 이 PR들을 열어 둡니다. 그동안 다음 단계로 진행할 수 있습니다.

안정화 보고서 작성하기

이 저장소에 있는 템플릿을 사용하여 안정화 보고서를 작성하십시오.

안정화 보고서는 다음 내용을 요약합니다:

RFC가 승인된 이후의 주요 설계 결정과 변경 사항입니다. 여기에는 FCP를 거쳤거나 그 밖의 방식으로 언어 팀이 승인한 결정과 lang 팀에 처음으로 제시되는 결정이 모두 포함됩니다.
- 최종적으로 안정화되는 언어 기능은 원래 RFC와 설계상 크게 달라지는 경우가 많습니다. 그래도 괜찮지만, 이러한 차이점은 반드시 강조하고 신중하게 설명해야 합니다.
RFC가 승인된 이후 수행된 작업입니다. 언어 기능을 진전시키는 데 기여한 주요 기여자들을 함께 밝힙니다.

안정화 템플릿에는 이 기능과 lang의 하위 팀(예: types, opsem, lang-docs 등) 사이의 연관성을 드러내고 흔히 간과되는 항목을 찾아내기 위한 일련의 질문이 포함되어 있습니다.

안정화 보고서는 일반적으로 안정화 PR의 주 댓글로 게시됩니다(다음 절을 참조하십시오).

안정화 PR

기능마다 사정이 다르며, 일부 기능에는 이 가이드에서 다루는 것 이상의 단계가 필요할 수 있습니다.

lang 팀이 안정화를 검토하려면 먼저 해당 기능을 설명하는 완전한 PR이 Reference에 제출되어 있어야 하며, 안정화 PR이 병합되기 전에 이 PR이 lang-docs 팀의 리뷰와 승인을 받아야 합니다.

기능 게이트 목록 업데이트하기

불안정 기능 게이트의 중앙 목록은 compiler/rustc_feature/src/unstable.rs에 있습니다. declare_features! 매크로를 검색하십시오. 안정화하려는 기능에 대한 항목이 다음과 비슷한 형태로 있을 것입니다(rust-lang/rust#32409에서 가져온 예시입니다).

// pub(restricted) visibilities (RFC 1422)
(unstable, pub_restricted, "CURRENT_RUSTC_VERSION", Some(32409)),

위 줄은 compiler/rustc_feature/src/accepted.rs로 옮겨야 합니다. declare_features! 호출 안의 항목들은 정렬되어 있으므로 올바른 위치를 찾으십시오. 작업을 마치면 다음과 같은 모습이어야 합니다.

// pub(restricted) visibilities (RFC 1422)
(accepted, pub_restricted, "CURRENT_RUSTC_VERSION", Some(32409)),
// note that we changed this

(파일에서 과거 변경 사항의 버전 번호를 보게 되더라도, 안정화가 이루어질 것으로 예상하는 rustc 버전을 적지 말고 대신 CURRENT_RUSTC_VERSION을 사용하십시오.)

다음으로, 코드베이스에서 기능 문자열(이 경우 pub_restricted)을 검색하여 어디에 나타나는지 찾으십시오. std와 모든 rustc 크레이트(library/와 compiler/ 아래의 테스트 폴더는 포함하지만 최상위 tests/ 폴더는 포함하지 않음)에서 #![feature(XXX)] 사용을 #![cfg_attr(bootstrap, feature(XXX))]로 변경하십시오. 이렇게 하면 현재 베타로 빌드되는 stage1에서만 기능 게이트가 포함됩니다(현재 베타에서는 해당 기능이 아직 불안정하므로 이 작업이 필요합니다).

또한 모든 테스트(예: tests/ 아래)에서 해당 문자열을 제거하십시오. 기능 게이트만을 대상으로 하는 테스트(즉, 기능을 사용하려면 기능 게이트가 필요하다는 것만 테스트하고 그 외에는 아무것도 테스트하지 않는 테스트)가 있다면 그 테스트를 그냥 제거하십시오.

기능을 사용할 때 기능 게이트를 요구하지 않게 하기

가장 중요한 것은 기능 게이트가 없을 때 오류 플래그를 띄우는 코드를 제거하는 것입니다(이제 해당 기능은 안정된 것으로 간주되기 때문입니다). 해당 기능이 새로운 구문을 사용하여 감지될 수 있다면, 그 코드는 흔히 compiler/rustc_ast_passes/src/feature_gate.rs에 있습니다. 예를 들어 다음과 같은 코드를 볼 수 있습니다.

gate_all!(pub_restricted, "`pub(restricted)` syntax is experimental");

gate_all! 매크로는 pub_restricted 기능이 활성화되지 않은 경우 오류를 보고합니다. 이제 pub(restricted)가 안정화되었으므로 이 코드는 더 이상 필요하지 않습니다.

더 미묘한 기능의 경우 다음과 같은 코드를 발견할 수 있습니다.

if self.tcx.features().async_fn_in_dyn_trait() { /* XXX */ }

이 pub_restricted 필드(기능 이름을 딴 것)는 보통 기능 플래그가 없으면 false이고, 있으면 true입니다. 따라서 이 필드가 true라고 가정하도록 코드를 변환하십시오. 이 경우에는 if를 제거하고 /* XXX */만 남기면 됩니다.

if self.tcx.sess.features.borrow().pub_restricted { /* XXX */ }
becomes
/* XXX */

if self.tcx.sess.features.borrow().pub_restricted && something { /* XXX */ }
 becomes
if something { /* XXX */ }

팀 지명

안정화 PR을 열 때 lang 팀과 그 자문단(@rust-lang/lang @rust-lang/lang-advisors), 그리고 해당 기능과 관련된 다른 모든 팀을 CC하십시오. 예를 들면 다음과 같습니다.

@rust-lang/types: 타입 시스템과의 상호 작용 관련
@rust-lang/opsem: unsafe 코드와의 상호 작용 관련
@rust-lang/compiler: 구현의 견고성 관련
@rust-lang/libs: 표준 라이브러리 API나 그 보장 사항을 변경하는 경우입니다.
@rust-lang/lang-docs: 이 기능을 Reference에 어떻게 문서화해야 하는지에 관한 질문이 있는 경우입니다.

안정화 보고서와 함께 안정화 PR을 연 뒤에는 곧바로 달리는 의견이 있는지 잠시 기다리십시오. 그런 의견이 “잦아들고” PR이 lang 팀의 검토를 받을 준비가 되었다고 판단되면, 다가오는 lang 회의에서 검토할 안건에 오르도록 PR을 지명하십시오.

rust-lang 조직의 구성원이 아니라면, 배정된 리뷰어에게 관련 팀을 대신 CC해 달라고 요청할 수 있습니다.

PR에 FCP 제안하기

lang 팀과 기타 관련 팀이 안정화를 검토하고 여러분이 그들의 질문에 모두 답변하고 나면, 해당 팀 중 한 팀의 구성원이 다음과 같이 댓글을 달아 안정화 수락을 제안할 수 있습니다.

@rfcbot fcp merge

충분한 수의 팀 구성원이 검토를 마치면 PR은 “최종 의견 수렴 기간”(FCP)에 들어갑니다. 새로운 우려 사항이 제기되지 않으면 이 기간이 끝나고, 통상적인 방식으로 구현 리뷰를 거친 뒤 PR을 병합할 수 있습니다.

안정화 리뷰 및 병합

안정화 PR에 r+를 주기 전에 PR이 다음 조건을 충족하는지 확인하십시오.

팀이 안정화를 위해 제안한 내용 및 Reference PR에 문서화된 내용과 일치합니다.
우려 사항을 해결하거나 피하기 위해 팀이 진행 과정에서 요청하기로 결정한 모든 변경 사항을 포함합니다.
그 밖의 부분은 안정화 보고서와 관련 RFC 또는 이전 lang FCP에 기술된 내용과 정확히 일치합니다.
명시되고, 안정화가 수락되고, Reference에 문서화된 동작 외에는 어떠한 동작도 stable에 노출하지 않습니다.
이러한 사항을 설득력 있게 입증할 만큼 충분한 테스트를 갖추고 있습니다.
lang-docs 구성원이 리뷰하고 승인한 Reference PR이 함께 제출되어 있습니다.

특히 PR을 리뷰할 때는 lang 팀이 미처 고려하거나 명시하지 못한, 사용자에게 드러나는 세부 사항이 있는지 주의 깊게 살피십시오. 그런 사항을 발견하면 이를 설명하고 lang 팀에 PR을 지명하십시오.

Rust 컴파일러 개발 가이드