시작하기

Rust에 기여하는 데 관심을 가져 주셔서 감사합니다! 기여하는 방법은 다양하며, 저희는 그 모든 기여에 감사드립니다.

Rust에 기여하는 방법에 관한 일반적인 정보는 Forge를 참고하십시오. 이 절의 나머지 부분은 특히 컴파일러에 기여하는 방법을 다룹니다.

이 문서는 모든 내용을 포괄하기 위한 것이 아니며, 가장 유용한 내용을 빠르게 안내하기 위한 것입니다. 자세한 내용은 컴파일러를 빌드하고 실행하는 방법을 참고하십시오.

도움 받기

“질문하기”도 참고하십시오.

전문가

모든 t-compiler 구성원이 rustc의 모든 부분에 정통한 것은 아닙니다. 상당히 큰 프로젝트이기 때문입니다. 컴파일러의 각 부분에 대해 누가 전문 지식을 갖추고 있는지 알아보려면 triagebot 할당 그룹을 참고하십시오. triagebot.toml 파일에서 [assign*로 시작하는 섹션들이 이에 해당합니다. 하지만 누구에게 핑을 보내야 할지 모르더라도 부담 없이 질문하십시오.

컴파일러의 특정 부분에 대한 전문가를 찾는 또 다른 방법은 최근에 누가 커밋했는지 살펴보는 것입니다. 예를 들어, 1.68.2 릴리스 이후 최근에 이름 해석 작업을 한 사람을 찾으려면 git shortlog -n 1.68.2.. compiler/rustc_resolve/를 실행하면 됩니다. “Rollup merge“로 시작하는 커밋이나 @bors가 만든 커밋은 무시하십시오(이러한 커밋에 대한 자세한 내용은 CI 기여 절차를 참고하십시오).

무엇을 작업해야 합니까?

rust 모노레포는 규모가 상당히 커서, 어느 부분에 도움이 필요한지, 또는 어느 부분이 초보자가 시작하기에 좋은지 알기 어려울 수 있습니다. 다음은 시작하기 좋은 곳으로 추천하는 몇 가지입니다.

쉬운 이슈 또는 멘토링이 제공되는 이슈

어디서부터 시작할지 찾고 계시다면 다음 이슈 검색을 확인해 보십시오. 이 레이블들에 대한 설명은 Triage를 참고하십시오. 관심 있는 분야로 검색을 필터링해 볼 수도 있습니다. 예를 들면 다음과 같습니다.

• label:T-compiler는 컴파일러와 관련된 이슈만 보여 줍니다
• label:A-diagnostics는 진단 관련 이슈만 보여 줍니다

중요한 작업이나 초보자용 작업에 모두 이슈 레이블이 붙어 있는 것은 아닙니다. 레이블이 붙지 않은 작업을 찾는 방법은 아래를 참고하십시오.

반복적인 작업

어떤 작업은 한 사람이 하기에는 너무 큽니다. 이런 경우에는 기여자들 사이의 작업을 조율하기 위해 “추적 이슈(Tracking issues)“를 두는 것이 일반적입니다. 다음은 많은 시간을 들이지 않고도 쉽게 작업을 맡을 수 있는 추적 이슈의 예입니다:

• 반복 작업 항목을 여기에 추가하십시오.

반복 작업을 더 발견하시면 언제든지 여기에 추가해 주십시오!

진단 이슈

많은 진단 이슈는 그 자체로 완결되어 있어 컴파일러에 대한 자세한 배경지식이 필요하지 않습니다. 진단 이슈 목록은 여기에서 볼 수 있습니다.

방치된 풀 리퀘스트 이어받기

때때로 기여자가 풀 리퀘스트를 보낸 뒤, 작업할 시간이 충분하지 않다는 것을 나중에 알게 되거나 단순히 더 이상 관심이 없어지는 경우가 있습니다. 이러한 PR은 결국 닫히는 경우가 많으며 S-inactive 레이블이 붙습니다. 이러한 PR 중 일부를 살펴보고 작업을 이어받아 볼 수 있습니다. 이러한 PR 목록은 여기에서 찾을 수 있습니다.

그사이에 해당 PR이 다른 방식으로 구현되었다면 그 PR에서 S-inactive 레이블을 제거해야 합니다. 그렇지 않고 해당 변경에 여전히 관심이 있는 것으로 보인다면, 풀 리퀘스트를 최신 main 브랜치 위로 리베이스한 뒤 새 풀 리퀘스트를 보내 해당 기능에 대한 작업을 이어갈 수 있습니다.

테스트 작성하기

해결되었지만 회귀 테스트가 없는 이슈에는 E-needs-test 레이블이 붙어 있습니다. 단위 테스트 작성은 위험이 적고 우선순위가 비교적 낮은 작업으로, 새로운 기여자가 테스트 인프라와 기여 워크플로에 익숙해질 수 있는 좋은 기회가 됩니다. 테스트가 필요한 이슈 목록은 여기에서 볼 수 있습니다.

std(표준 라이브러리)에 기여하기

std-dev-guide를 참고하십시오.

그 밖의 기여 방법

Forge를 참고하십시오.

클론 및 빌드

“컴파일러를 빌드하고 실행하는 방법”을 참고하십시오.

버그 수정 또는 “일반적인” 코드 변경

대부분의 PR에는 특별한 절차가 필요하지 않습니다. PR을 열기만 하면 리뷰와 승인을 거쳐 병합됩니다. 여기에는 대부분의 버그 수정, 리팩터링, 그 밖에 사용자에게 보이지 않는 변경이 포함됩니다. 다음 몇 개의 절에서는 이 규칙의 예외를 설명합니다.

또한 WIP PR이나 GitHub Draft PR을 여는 것도 전혀 문제가 없다는 점에 유의하십시오. 어떤 사람들은 작업 도중에 피드백을 받거나 협업자와 코드를 공유하기 위해 이 방식을 선호합니다. 또 어떤 사람들은 CI를 활용하여 자신의 PR을 빌드하고 테스트하기 위해 이 방식을 사용합니다(예: 느린 머신에서 개발하는 경우).

풀 리퀘스트

풀 리퀘스트(줄여서 PR)는 Rust를 변경하는 데 사용하는 주된 수단입니다. GitHub 자체에도 풀 리퀘스트 기능 사용법에 관한 훌륭한 문서가 있습니다. 저희는 “fork and pull” 모델을 사용합니다. 이 모델에서 기여자는 개인 포크에 변경 사항을 푸시하고, 그 변경 사항을 원본 저장소에 반영하기 위해 풀 리퀘스트를 생성합니다. Rust에 기여할 때 Git을 사용하는 방법에 관한 장도 마련되어 있습니다.

규모가 크거나, 복잡하거나, 여러 영역에 걸치거나, 매우 특정 도메인에 국한될 수 있는 변경에 대한 조언

순번제로 리뷰를 맡는 컴파일러 리뷰어들은 대개 각자 잘 아는 컴파일러 영역이 있지만, 그다지 익숙하지 않은 영역도 있습니다. PR에 규모가 크거나, 복잡하거나, 여러 영역에 걸치거나, 매우 특정 도메인에 국한된 변경이 포함되어 있다면, 그러한 PR의 모든 변경 사항을 무리 없이 리뷰할 수 있는 적절한 리뷰어를 찾기가 매우 어려워집니다. 변경 사항이 컴파일러에만 국한되지 않고 표준 라이브러리 팀처럼 다른 팀 리뷰어의 소관에 속하는 변경까지 포함하는 경우에도 마찬가지입니다. 수정된 파일을 기준으로 관련 팀에 알리고 특정 알림을 설정해 둔 사람들을 호출하는 봇이 있습니다.

이러한 변경을 하기 전에 제안하는 변경 사항을 컴파일러 팀과 미리 논의하고(변경에 승인이 필요한 다른 팀과도 논의하십시오), 컴파일러 팀과 협력하여 리뷰하기 어려울 수 있는 큰 PR을 개별적으로 리뷰하기 더 쉬운 작은 PR 여러 개로 나누는 데 도움을 받을 수 있는지 확인하기를 강력히 권장합니다.

Zulip에 #t-compiler 스레드를 만들어 제안하는 변경 사항을 논의함으로써 컴파일러 팀과 소통할 수 있습니다.

컴파일러 팀과 미리 소통하면 여러 면에서 도움이 됩니다.

1. PR이 적시에 리뷰될 가능성이 높아집니다.
   • 실제 PR을 열기 전에 적절한 리뷰어를 찾도록 도와드리거나, 변경 절차를 진행하는 데 도움을 줄 조언자와 연락 담당자를 찾아 드리거나, 필요에 따라 try-job, perf 실행, crater 실행을 도와드릴 수 있습니다.
2. 컴파일러 팀이 변경 사항을 추적하는 데 도움이 됩니다.
3. 컴파일러 팀은 변경 방향이 컴파일러 팀이 선호하는 방향과 일치하는지 확인하기 위해 변경 사항을 일찍부터 자주 가볍게 점검(vibe check)할 수 있습니다.
4. 컴파일러 팀이 받아들이지 않을 수도 있는 큰 변경에 상당한 시간과 노력을 들이거나, 변경 방향이 컴파일러 팀의 의견과 다르다는 사실을 너무 늦게 알게 되는 상황을 피하는 데 도움이 됩니다.

이슈 분류

https://forge.rust-lang.org/release/issue-triaging.html을 참조하십시오.

기타 자료

이 절은 “이 가이드에 대하여” 장으로 옮겨졌습니다.