Esta é a casa das especificações Scala 2 Standard Library, Compiler e Language.
Para Scala 3, visite scala/scala3.
Problemas e relatórios de bugs para scala 2 estão localizados em scala/bug. Esse rastreador também é onde os novos colaboradores podem encontrar problemas para trabalhar: Boas primeiras questões, ajuda de ajuda.
Para coordenar esforços mais amplos, também usamos o rastreador Scala/Scala-Dev.
Para contribuir aqui, abra uma solicitação de tração do seu garfo deste repositório.
Esteja ciente de que não podemos aceitar adições à biblioteca padrão, apenas modificações no código existente. A compatibilidade binária proíbe a adição de novas classes públicas ou métodos públicos. Em vez disso, são feitas adições ao Scala-Library-Next.
Exigimos que você assine o Scala CLA antes que possamos mesclar qualquer um de seu trabalho, para proteger o futuro do Scala como software de código aberto.
O fluxo de trabalho geral é o seguinte.
Para obter mais informações sobre a construção e o desenvolvimento do núcleo do Scala, leia o restante deste ReadMe, especialmente para configurar sua máquina!
Para entrar em contato com outros colaboradores da Scala, junte-se ao canal #Scala-Countributores no bate-papo do Scala Discord ou publique em colaboradores.scala--blang.org (discurso).
Se você precisar de ajuda com seu PR a qualquer momento, sinta-se à vontade para @-MENTION qualquer pessoa da lista abaixo, e faremos o possível para ajudá-lo:
| nome de usuário | Fale comigo sobre ... | |
|---|---|---|
@lrytz | Back -end, Optimizer, nomeado e argumentos padrão, repórteres | |
@retronym | 2.12.x ramo, desempenho do compilador, bugs de compilador estranho, lambdas | |
@SethTisue | Introdução, construção, IC, Community Build, Jenkins, Docs, Biblioteca, Repl | |
@dwijnand | Matcário de padrões, Mima, Parest | |
@som-snytt | avisos/fiapos/erros, repl, opções de compilador, internos do compilador, Parest | |
@Ichoran | Biblioteca de Coleções, Desempenho | |
@viktorklang | simultaneidade, futuros | |
@sjrd | Interações com Scala.js | |
@NthPortal | biblioteca, concorrência, scala.math , LazyList , Using , avisos | |
@bishabosha | Leitor saboroso | |
@joroKr21 | Tipos, implícitos, variação de madeiras superiores |
PS: Se você tiver algum tempo livre para ajudar por aqui, ficaríamos encantados em adicionar seu nome a esta lista!
Alvo o ramo mais antigo que você gostaria que suas alterações acabem. Periodicamente, nos fundimos para a frente de ramificações de liberação mais antigas (por exemplo, 2.12.x) para novas (por exemplo, 2.13.x).
Se a sua alteração for difícil de se fundir, pode ser solicitado que você também envie um PR separado, direcionado à filial mais recente.
Se sua alteração for específica da versão e não deve ser mesclada, coloque [nomerge] no nome do PR.
Se sua alteração for um backport de uma ramificação mais recente e, portanto, não precisar ser mesclada para a frente, coloque [backport] no nome do PR.
A maioria das mudanças deve ter como alvo 2.13.x. Estamos cada vez mais relutantes em alvo 2.12.x, a menos que haja um motivo especial (por exemplo, se um bug especialmente ruim for encontrado ou se houver patrocínio comercial).
A filial 2.11.x agora está inativa e não há mais versões de 2.11.x mais planejadas (a menos que surjam circunstâncias incomuns e imprevisíveis). Você não deve segmentar 2.11.x sem pedir aos mantenedores primeiro.
O mais importante:
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
Mas também:
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
Você precisa das seguintes ferramentas:
MacOS e Linux trabalham. O Windows pode funcionar se você usar o Cygwin. A ajuda da comunidade para manter a construção trabalhando no Windows e documentando qualquer configuração necessária é apreciada.
Somos gratos pelas seguintes licenças OSS:
Durante o desenvolvimento comum, uma nova compilação do Scala é construída pela versão lançada anteriormente, conhecida como "Compilador de referência" ou, gíriaz, como "Starr" (versão estável de referência). Construir com Starr é suficiente para a maioria dos tipos de mudanças.
No entanto, uma construção completa de Scala é inicializada . O Bootstrapping tem duas etapas: primeiro, construa com Starr; Em seguida, construa novamente usando o compilador recém -construído, deixando Starr para trás. Isso garante que toda versão do Scala possa se construir.
Se você alterar a parte da geração de código do compilador Scala, suas alterações serão exibidas apenas no bytecode da biblioteca e do compilador após uma bootstrap. Nosso CI faz uma construção inicializada.
Bootstrapping localmente : para executar um bootstrap, execute restarrFull dentro de uma sessão do SBT. Isso criará e publicará a distribuição do Scala ao seu repositório de artefato local e, em seguida, trocará o SBT para usar essa versão como sua nova scalaVersion . Você pode então voltar a reload . Nota restarrFull também escreverá a versão Starr para buildcharacter.properties , para que você possa voltar a ele com restarr sem republicar. Isso mudará a sessão do SBT para usar os diretórios build-restarr e target-restarr em vez de build e target , o que evita a eliminação de arquivos de classe e metadados incrementais. O Intellij continuará sendo configurado para compilar e executar testes usando a versão Starr em versions.properties .
Para a história sobre como o esquema atual foi alcançado, consulte https://groups.google.com/d/topic/scala-internals/gp5jsm1e0fo/discussion.
Construindo com avisos fatais : para fazer avisos no projeto fatal (ou seja, transformá -los em erros), execute set Global / fatalWarnings := true no sbt (substitua Global pelo nome de um módulo - como reflect - para fazer apenas avisos fatais para aquele módulo). Para desativar os avisos fatais novamente, reload o SBT, ou execute set Global / fatalWarnings := false (novamente, substitua Global pelo nome de um módulo se você ativou apenas avisos fatais para esse módulo). O CI sempre tem avisos fatais ativados.
Depois de iniciar uma sessão sbt , você pode executar um dos comandos principais:
compile compila todos os subprojetos (biblioteca, refletir, compilador, scaladoc, etc)scala / scalac execute o repl / compilador diretamente do sbt (aceitar opções / argumentos)enableOptimizer Recarrega a compilação com o otimizador de Scala ativado. Nossos lançamentos são construídos dessa maneira. Habilite isso ao trabalhar em melhorias no desempenho do compilador. Quando o otimizador estiver ativado, a compilação será mais lenta e as construções incrementais podem estar incorretas.setupPublishCore enableOptimizer e configura um número de versão com base no atual git sha. Freqüentemente usado como parte do bootstrapping: sbt setupPublishCore publishLocal && sbt -Dstarr.version=<VERSION> testAlldist/mkBin gera scripts corredores ( scala , scalac , etc) em build/quick/bindist/mkPack cria uma construção no formato de distribuição de Scala no build/packjunit/test realiza os testes Junit; junit/testOnly *Foo executa um subconjuntoscalacheck/test executa testes de Scalacheck, use testOnly para executar um subconjuntopartest partest --helppublishLocal publica uma distribuição localmente (pode ser usada como scalaVersion em outros projetos SBT)set baseVersionSuffix := "bin-abcd123-SNAPSHOT" , onde abcd123 é o hash git da revisão que está sendo publicada. Você também pode usar algo personalizado como "bin-mypatch" . Isso altera o número da versão de 2.13.2-SNAPSHOT para algo mais estável ( 2.13.2-bin-abcd123-SNAPSHOT ).-bin marca a versão binária compatível. Usá -lo no SBT fará com que o scalaBinaryVersion seja 2.13 . Se a versão não for compatível binária, recomendamos o uso -pre , por exemplo, 2.14.0-pre-abcd123-SNAPSHOT .set ThisBuild / Compile / packageDoc / publishArtifact := false to pular os documentos API de geração / publicação (acelera o processo). Se um comando resultar em uma mensagem de erro como a module is not authorized to depend on itself , pode ser que um plugin SBT global esteja causando uma dependência cíclica. Tente desativar os plugins SBT globais (talvez com comentários temporariamente em ~/.sbt/1.0/plugins/plugins.sbt ).
Recomendamos manter os arquivos de teste local no diretório sandbox , listados no .gitignore do repo Scala.
Observe que a compilação incremental do SBT geralmente é muito grossa para a base de código do Scala Compiler e recorrente a muitos arquivos, resultando em longos tempos de construção (verifique o SBT#1104 para progresso nessa frente). Enquanto isso, você pode:
Sugerimos usar o Intellij IDEA (ver SRC/Intellij/Readme.md).
Os metais também podem funcionar, mas ainda não temos instruções ou configuração de amostra para isso. Uma solicitação de tração nesta área seria extremamente bem -vinda. Enquanto isso, estamos coletando orientações no Scala/Scala-Dev#668.
Para usar o compilador incremental da Intellij:
dist/mkBin no SBT para obter uma construção e os scripts do corredor em build/quick/bin Agora você pode editar e construir no Intellij e usar os scripts (compilador, REPL) para testar diretamente suas alterações. Você também pode executar os comandos scala , scalac e partest no SBT. Ativar "Modo Ant" (explicado acima) para impedir que o compilador incremental do SBT recilulgue (muitos) arquivos antes de cada invocação partest .
Nossas diretrizes para contribuir são explicadas em contribuições.md. Ele contém informações úteis sobre nossos padrões de codificação, testes, documentação, como usamos o Git e o Github e como a revisão do código.
Você também pode querer verificar os seguintes recursos:
Depois de enviar um PR, seus compromissos serão testados automaticamente pelo Scala CI.
Nossa configuração de CI está sempre evoluindo. Veja Scala/Scala-Dev#751 para obter mais detalhes sobre como as coisas funcionam atualmente e como esperamos que elas mudem.
Se você vir uma falha espúria em Jenkins, poderá postar /rebuild como um comentário de relações públicas. O Scabot ReadMe lista todos os comandos disponíveis.
Se você deseja testar seu patch antes de ter tudo polido para revisão, pode ter o Travis CI construir sua filial (verifique se você tem um garfo e que o Travis CI habilitado para as construções de ramificação primeiro e depois empurre seu ramo). Também fique à vontade para enviar um rascunho de relações públicas. Caso sua filial de rascunho contenha um grande número de commits (que você ainda não limpa / abóbora para revisão), considere adicionar [ci: last-only] ao título de RP. Dessa forma, apenas o último compromisso será testado, economizando alguma energia e recursos de CI. Observe que o PRS de rascunho inativo será fechado eventualmente, o que não significa que a mudança esteja sendo rejeitada.
O CI executa um bootstrap de compilador. A primeira tarefa, validatePublishCore , publica uma construção do seu compromisso com o repositório temporário https://scala-ci.typesafe.com/artifactory/scala-pr-validation-snapshots. Observe que esta compilação ainda não está inicializada, seu bytecode é construído usando o Starr atual. O número da versão é 2.13.2-bin-abcd123-SNAPSHOT onde abcd123 é o hash de comprometimento. Para compilações incompatíveis binárias, o número da versão é 2.14.0-pre-abcd123-SNAPSHOT .
Você pode usar as compilações do Scala no repositório de validação localmente adicionando um resolvedor e especificando a scalaVersion correspondente:
$ sbt
> set resolvers += "pr" at "https://scala-ci.typesafe.com/artifactory/scala-pr-validation-snapshots/"
> set scalaVersion := "2.12.2-bin-abcd123-SNAPSHOT"
> console
O Scala CI os publica em https://scala-ci.typesafe.com/artifactory/scala-integration/.
Usando uma construção noturna no SBT e outras ferramentas é explicada nesta página do documento.
Embora nos referamos casualmente a isso como construções "noturnas", elas não são realmente construídas todas as noites, mas "Mergely". Ou seja, uma construção é publicada para cada relações públicas mescladas.
O Scala CI é executado como uma instância de Jenkins no scala-ci.typesafe.com, configurada por um livro de receitas de chef no Scala/Scala-Jenkins-Infra.
O bot de compilação que assiste aos PRs, desencadeia o teste construir e aplica o rótulo "revisado" após um comentário LGTM no repositório Scala/Scabot.
A construção da comunidade Scala é um método importante para testar as liberações do Scala. Uma compilação da comunidade pode ser lançada para qualquer commit scala, mesmo antes que o PR do Commit seja mesclado. Essa confirmação é usada para criar um grande número de projetos de código aberto a partir da fonte e executar suas suítes de teste.
Para solicitar uma construção da comunidade, basta pedir um comentário sobre o PR e um membro da equipe da Scala (provavelmente @Sethtisue) cuidará dele. (detalhes)
As construções da comunidade são executadas na instância de Scala Jenkins. Os trabalhos são nomeados ..-integrate-community-build . Veja o repo Scala/Community-Builds.