scala
Scala 2.13.15
이것은 Scala 2 표준 라이브러리, 컴파일러 및 언어 사양의 고향입니다.
Scala 3의 경우 Scala/Scala3을 방문하십시오.
Scala 2의 문제 및 버그 보고서는 Scala/Bug에 있습니다. 이 트래커는 또한 새로운 기고자가 작업해야 할 문제를 찾을 수있는 곳입니다. 좋은 첫 번째 문제, 도움이 필요합니다.
광범위한 노력을 조정하기 위해 Scala/Scala-Dev 트래커도 사용합니다.
여기에 기여하려면이 저장소의 포크에서 풀 요청을 열어주십시오.
표준 라이브러리에 대한 추가를 수락 할 수 없으며 기존 코드에 대한 수정 만 허용 할 수 없습니다. 이진 호환성은 새로운 공개 클래스 또는 공개 방법을 추가하는 것을 금지합니다. 대신 Scala-library-next에 추가됩니다.
Scala의 미래를 오픈 소스 소프트웨어로 보호하기 위해 귀하의 작업을 병합하기 전에 Scala CLA에 서명해야합니다.
일반적인 워크 플로는 다음과 같습니다.
Scala의 핵심 구축 및 개발에 대한 자세한 내용은 특히 기계를 설정하기 위해이 readme의 나머지 부분을 읽으십시오!
다른 스칼라 기고자들과 연락하기 위해 Scala Discord Chat의 #Scala-Contripors 채널에 가입하거나 Contributors.scala-lang.org (담론)에 게시하십시오.
언제든지 PR에 대한 도움이 필요한 경우 아래 목록에서 @-mention을 자유롭게 받으십시오. 우리는 당신을 도와 줄 것입니다.
| 사용자 이름 | 나에게 얘기 ... ... | |
|---|---|---|
@lrytz | 백엔드, Optimizer, 명명 및 기본 인수, 기자 | |
@retronym | 2.12.x 브랜치, 컴파일러 성능, 이상한 컴파일러 버그, 람다 | |
@SethTisue | 시작, 빌드, CI, 커뮤니티 빌드, Jenkins, Docs, Library, Repl | |
@dwijnand | Pattern Matcher, Mima, Partest | |
@som-snytt | 경고/린트/오류, REPL, 컴파일러 옵션, 컴파일러 내부, 파트 | |
@Ichoran | 컬렉션 라이브러리, 성능 | |
@viktorklang | 동시성, 미래 | |
@sjrd | scala.js와의 상호 작용 | |
@NthPortal | 도서관, 동시성, scala.math , LazyList , Using , 경고 | |
@bishabosha | 맛있는 독자 | |
@joroKr21 | 더 높은 가게 유형, 암시, 분산 |
추신 : 여기 주변에서 도울 여가 시간이 있다면, 우리는이 목록에 당신의 이름을 추가하게 된 것을 기쁘게 생각합니다!
변경 사항이 끝나기를 원하는 가장 오래된 지점을 대상으로합니다. 우리는 정기적으로 구형 릴리스 브랜치 (예 : 2.12.x)에서 새로운 제품 (예 : 2.13.x)으로 주기적으로 병합됩니다.
변경 사항을 전진하기가 어려운 경우 최신 지점을 대상으로하는 별도의 PR을 제출하라는 요청을받을 수 있습니다.
변경 사항이 버전에 따라 다르고 앞으로 병합되어서는 안되는 경우 [nomerge] PR 이름으로 넣으십시오.
변경 사항이 최신 지점의 백 포트 인 경우 앞으로 병합 될 필요가 없다면 PR 이름에 [backport] 넣으십시오.
대부분의 변경 사항은 2.13.x를 대상으로해야합니다. 우리는 특별한 이유가 없다면 (특히 나쁜 버그가 발견되거나 상업적 후원이있는 경우) 2.12.x를 목표로하는 것을 꺼려합니다.
2.11.x 브랜치는 이제 비활성화되어 있으며 더 이상 2.11.x 릴리스가 계획되지 않습니다 (비정상적이고 예측할 수없는 상황이 발생하지 않는 한). 관리자에게 먼저 묻지 않고 2.11.x를 목표로 삼아서는 안됩니다.
가장 중요한 것은 :
scala/
+--build.sbt The main sbt build definition
+--project/ The rest of the sbt build
+--src/ All sources
+---/library Scala Standard Library
+---/reflect Scala Reflection
+---/compiler Scala Compiler
+--test/ The Scala test suite
+---/files Partest tests
+---/junit JUnit tests
+---/scalacheck ScalaCheck tests
+--spec/ The Scala language specification
그러나 또한 :
scala/
+---/library-aux Scala Auxiliary Library, for bootstrapping and documentation purposes
+---/interactive Scala Interactive Compiler, for clients such as an IDE (aka Presentation Compiler)
+---/intellij IntelliJ project templates
+---/manual Scala's runner scripts "man" (manual) pages
+---/partest Scala's internal parallel testing framework
+---/partest-javaagent Partest's helper java agent
+---/repl Scala REPL core
+---/repl-frontend Scala REPL frontend
+---/scaladoc Scala's documentation tool
+---/scalap Scala's class file decompiler
+---/testkit Scala's unit-testing kit
+--admin/ Scripts for the CI jobs and releasing
+--doc/ Additional licenses and copyrights
+--scripts/ Scripts for the CI jobs and releasing
+--tools/ Scripts useful for local development
+--build/ Build products
+--dist/ Build products
+--target/ Build products
다음 도구가 필요합니다.
MacOS 및 Linux 작업. Cygwin을 사용하는 경우 Windows가 작동 할 수 있습니다. 커뮤니티는 Windows에서 빌드를 유지하고 필요한 설정을 문서화하는 데 도움이됩니다.
다음 OSS 라이센스에 감사드립니다.
평범한 개발 중에, 새로운 스칼라 빌드는 "참조 컴파일러"또는 Slangily, "Starr"(안정적인 참조 릴리스)로 알려진 이전에 출시 된 버전에 의해 구축됩니다. Starr로 건축하면 대부분의 종류의 변화에 충분합니다.
그러나 스칼라의 전체 빌드가 부트 스트랩 됩니다. 부트 스트래핑은 두 단계가 있습니다. 첫째, Starr로 빌드하십시오. 그런 다음 새로 제작 된 컴파일러를 사용하여 다시 빌드하여 Starr를 남겨 두십시오. 이를 통해 모든 스칼라 버전이 자체적으로 구축 될 수 있습니다.
스칼라 컴파일러의 코드 생성 부분을 변경하면 부트 스트랩 후 라이브러리 및 컴파일러의 바이트 코드에만 변경 사항이 나타납니다. 우리의 CI는 부트 스트랩 빌드를 수행합니다.
로컬로 부트 스트랩 : 부트 스트랩을 수행하려면 SBT 세션 내에서 restarrFull 실행하십시오. 이것은 스칼라 분포를 로컬 아티팩트 리포지토리에 구축하고 게시 한 다음 SBT를 전환하여 해당 버전을 새로운 scalaVersion 으로 사용합니다. 그런 다음 다시 reload 로 되돌아 갈 수 있습니다. 참고 restarrFull 또한 starr 버전을 작성하여 buildcharacter.properties 작성하여 다시 출판없이 restarr 로 다시 전환 할 수 있습니다. 이렇게하면 SBT 세션을 전환하여 빌드 및 target 대신 build build-restarr 및 target-restarr 디렉토리를 사용하여 ClassFiles 및 증분 메타 데이터를 삭제하지 않습니다. Intellij는 versions.properties 에서 Starr 버전을 사용하여 테스트를 컴파일하고 실행하도록 계속 구성됩니다.
현재 체계가 어떻게 도착했는지에 대한 역사는 https://groups.com/d/topic/scala-internals/gp5jsm1e0fo/discustion을 참조하십시오.
치명적인 경고로 건축 : 프로젝트에서 치명적인 경고를 내리기 위해 (즉, 오류로 바꾸는), set Global / fatalWarnings := true (모듈의 이름으로 Global 대체 - reflect - 그 모듈). 치명적인 경고를 다시 비활성화하려면 SBT Global reload 하거나 set Global / fatalWarnings := false 실행하십시오. CI에는 항상 치명적인 경고가 가능합니다.
sbt 세션을 시작한 후에는 핵심 명령 중 하나를 실행할 수 있습니다.
compile 컴파일 모든 하위 프로젝트 (라이브러리, 반사, 컴파일러, Scaladoc 등)scala / scalac SBT에서 직접 Repl / Compiler를 실행합니다 (수락 옵션 / 인수)enableOptimizer 스칼라 최적화기를 활성화하여 빌드를 다시로드합니다. 우리의 릴리스는 이런 식으로 구축됩니다. 컴파일러 성능 향상에서 작업 할 때이를 활성화하십시오. 최적화기가 활성화되면 빌드가 느려지고 증분 빌드가 잘못 될 수 있습니다.setupPublishCore enableOptimizer 실행하고 현재 GIT SHA를 기반으로 버전 번호를 구성합니다. 부트 스트랩의 일부로 자주 사용 : sbt setupPublishCore publishLocal && sbt -Dstarr.version=<VERSION> testAlldist/mkBin build/quick/bin 에서 러너 스크립트 ( scala , scalac 등)를 생성합니다.dist/mkPack build/pack 의 스칼라 분포 형식으로 빌드를 만듭니다.junit/test Junit Tests를 실행합니다. junit/testOnly *Foo 서브 세트를 실행합니다scalacheck/test Scalacheck 테스트를 실행하고 testOnly 사용하여 하위 집합을 실행합니다.partest 실행 파트 테스트 (옵션 수락, partest --help )publishLocal 로컬로 배포를 게시합니다 (다른 SBT 프로젝트에서는 scalaVersion 으로 사용될 수 있음)abcd123 set baseVersionSuffix := "bin-abcd123-SNAPSHOT" "bin-mypatch" 와 같은 사용자 정의를 사용할 수도 있습니다. 이것은 버전 번호를 2.13.2-SNAPSHOT 에서 더 안정적인 것으로 변경합니다 ( 2.13.2-bin-abcd123-SNAPSHOT ).-bin 문자열은 버전 바이너리와 호환됩니다. SBT에 사용하면 scalaBinaryVersion Version이 2.13 됩니다. 버전이 이진 호환성이없는 경우 -pre , 예를 들어 2.14.0-pre-abcd123-SNAPSHOT 사용하는 것이 좋습니다.set ThisBuild / Compile / packageDoc / publishArtifact := false . 명령이 a module is not authorized to depend on itself 경우 글로벌 SBT 플러그인이 주기적 종속성을 유발할 수 있습니다. 글로벌 SBT 플러그인을 비활성화해보십시오 (아마도 ~/.sbt/1.0/plugins/plugins.sbt 에서 일시적으로 댓글을 달아서).
Scala Repo의 .gitignore 에 나열된 sandbox 디렉토리에 로컬 테스트 파일을 유지하는 것이 좋습니다.
SBT의 증분 컴파일은 종종 스칼라 컴파일러 코드베이스에 비해 너무 거칠고 너무 많은 파일을 다시 컴파일하여 빌드 시간이 길어집니다 (앞면의 진행 상황을 확인). 그 동안 당신은 할 수 있습니다.
Intellij 아이디어를 사용하는 것이 좋습니다 (SRC/Intellij/Readme.md 참조).
금속도 효과가있을 수 있지만 아직 지침이나 샘플 구성이 없습니다. 이 영역의 풀 요청은 매우 환영합니다. 그 동안 우리는 Scala/Scala-Dev#668에서 지침을 수집하고 있습니다.
Intellij의 증분 컴파일러를 사용하기 위해 :
dist/mkBin 실행하여 빌드 및 러너 스크립트를 build/quick/bin 에서 얻습니다. 이제 Intellij를 편집하고 빌드하고 스크립트 (컴파일러, REPL)를 사용하여 변경 사항을 직접 테스트 할 수 있습니다. SBT에서 scala , scalac 및 partest 명령을 실행할 수도 있습니다. 각 partest 호출 전에 SBT의 증분 컴파일러가 파일을 다시 컴파일하는 것을 방지하기 위해 "개미 모드"(위에 설명)를 활성화합니다.
기여에 대한 우리의 지침은 Contributing.md에 설명되어 있습니다. 코딩 표준, 테스트, 문서, GIT 및 GitHub 사용 방법 및 코드를 검토하는 방법에 대한 유용한 정보가 포함되어 있습니다.
다음 리소스를 확인할 수도 있습니다.
PR을 제출하면 Scala CI에 의해 커밋이 자동으로 테스트됩니다.
우리의 CI 설정은 항상 진화하고 있습니다. 현재 작동 방식과 변화가 어떻게 변할 수 있는지에 대한 자세한 내용은 Scala/Scala-Dev#751을 참조하십시오.
Jenkins에 가짜 실패가 발생하면 PR 댓글로 게시 /rebuild 할 수 있습니다. 딱지 readme에는 사용 가능한 모든 명령이 나열됩니다.
검토를 위해 모든 것을 연마하기 전에 패치를 테스트하려면 Travis CI가 지점을 만들 수 있습니다 (포크가 있고 지점을 먼저 빌드 할 수 있도록 Travis CI를 활성화 한 다음 지점을 밀어 넣으십시오). 또한 PR 초안을 제출하십시오. Draft Branch에 수많은 커밋 (아직 정리 / 스쿼시가 아직 검토를 위해 스쿼시를하지 않음)이 포함되어 있으면 PR 제목에 [ci: last-only] 를 추가하는 것을 고려하십시오. 이렇게하면 마지막 커밋 만 테스트하여 일부 에너지와 CI 자원을 절약 할 수 있습니다. 비활성 초안 PR이 결국 폐쇄되므로 변경이 거부되고 있음을 의미하지는 않습니다.
CI는 컴파일러 부트 스트랩을 수행합니다. 첫 번째 작업 인 validatePublishCore 는 임시 저장소 https://scala-ci.typesafe.com/artifactory/scala-pr-validation-snapshots에 대한 커밋 빌드를 게시합니다. 이 빌드는 아직 부트 스트랩되지 않았으며 바이트 코드는 현재 Starr를 사용하여 구축되었습니다. 버전 번호는 2.13.2-bin-abcd123-SNAPSHOT 이며 abcd123 커밋 해시입니다. 바이너리 호환 빌드의 경우 버전 번호는 2.14.0-pre-abcd123-SNAPSHOT 입니다.
Resolver를 추가하고 해당 scalaVersion 지정하여 유효성 검사 저장소에서 Scala Builds를 로컬로 사용할 수 있습니다.
$ sbt
> set resolvers += "pr" at "https://scala-ci.typesafe.com/artifactory/scala-pr-validation-snapshots/"
> set scalaVersion := "2.12.2-bin-abcd123-SNAPSHOT"
> console
Scala CI는 이것을 https://scala-ci.typesafe.com/artifactory/scala-integration/에 게시합니다.
SBT 및 기타 도구에서 야간 빌드를 사용하는 것은이 문서 페이지에 설명되어 있습니다.
비록 우리는 이것을 "야간"빌드라고 말하지만 실제로는 밤마다 지어진 것이 아니라 "Mergely"입니다. 즉, 모든 병합 PR에 대한 빌드가 게시됩니다.
Scala CI는 Scala/Scala-Jenkins-Infra의 Chef Cookbook에서 구성된 Scala-Ci.typesafe.com에서 Jenkins 인스턴스로 실행됩니다.
LGTM 댓글이 Scala/Scabot Repo에있는 후 PRS를 시청하고 테스트를 트리거하고 "검토 된"레이블을 적용합니다.
Scala Community Build는 스칼라 릴리스를 테스트하는 데 중요한 방법입니다. Commit의 PR이 병합되기 전에도 Scala Commit에 대한 커뮤니티 빌드를 시작할 수 있습니다. 그런 다음이 커밋은 소스에서 많은 오픈 소스 프로젝트를 구축하고 테스트 스위트를 운영하는 데 사용됩니다.
PR에 대한 커뮤니티 빌드를 요청하려면 PR에 대한 의견으로 스칼라 팀원 (아마도 @sethtisue)이이를 처리 할 것입니다. (세부)
Scala Jenkins 인스턴스에서 커뮤니티 빌드가 실행됩니다. 작업의 이름은 ..-integrate-community-build . Scala/Community-Builds Repo를 참조하십시오.
