Merge branch 'lampepfl:main' into dotty-scaladoc

Author: michelou

.github/workflows/ci.yaml

@@ -111,7 +111,7 @@ jobs:
 
       - name: Cmd Tests
         run: |
-          ./project/scripts/sbt ";dist/pack; scala3-bootstrapped/compile; scala3-bootstrapped/test;sjsSandbox/run;sjsSandbox/test;sjsJUnitTests/test;sjsCompilerTests/test ;sbt-test/scripted scala2-compat/* ;configureIDE ;stdlib-bootstrapped/test:run ;stdlib-bootstrapped-tasty-tests/test; scala3-compiler-bootstrapped/scala3CompilerCoursierTest:test"
+          ./project/scripts/sbt ";dist/pack; scala3-bootstrapped/compile; scala3-bootstrapped/test;sjsSandbox/run;sjsSandbox/test;sjsJUnitTests/test;sjsCompilerTests/test ;sbt-test/scripted scala2-compat/* ;stdlib-bootstrapped/test:run ;stdlib-bootstrapped-tasty-tests/test; scala3-compiler-bootstrapped/scala3CompilerCoursierTest:test"
           ./project/scripts/cmdTests
           ./project/scripts/bootstrappedOnlyCmdTests
 
@@ -232,6 +232,10 @@ jobs:
           git submodule update --init --recursive --jobs 7
           ./project/scripts/sbt "community-build/testOnly dotty.communitybuild.CommunityBuildTestA"
 
+      - name: Show dependency tracking file
+        if: ${{ always() }}
+        run: cat community-build/dotty-community-build-deps || true
+
   community_build_b:
     runs-on: [self-hosted, Linux]
     container:
@@ -275,6 +279,10 @@ jobs:
           git submodule update --init --recursive --jobs 7
           ./project/scripts/sbt "community-build/testOnly dotty.communitybuild.CommunityBuildTestB"
 
+      - name: Show dependency tracking file
+        if: ${{ always() }}
+        run: cat community-build/dotty-community-build-deps || true
+
   community_build_c:
     runs-on: [self-hosted, Linux]
     container:
@@ -318,6 +326,10 @@ jobs:
           git submodule update --init --recursive --jobs 7
           ./project/scripts/sbt "community-build/testOnly dotty.communitybuild.CommunityBuildTestC"
 
+      - name: Show dependency tracking file
+        if: ${{ always() }}
+        run: cat community-build/dotty-community-build-deps || true
+
   community_build_forward_compat:
     runs-on: [self-hosted, Linux]
     container:
@@ -447,7 +459,7 @@ jobs:
 
       - name: Test
         run: |
-          ./project/scripts/sbt ";dist/pack ;scala3-bootstrapped/compile ;scala3-bootstrapped/test;sjsSandbox/run;sjsSandbox/test;sjsJUnitTests/test;sjsCompilerTests/test ;sbt-test/scripted scala2-compat/* ;configureIDE ;stdlib-bootstrapped/test:run ;stdlib-bootstrapped-tasty-tests/test"
+          ./project/scripts/sbt ";dist/pack ;scala3-bootstrapped/compile ;scala3-bootstrapped/test;sjsSandbox/run;sjsSandbox/test;sjsJUnitTests/test;sjsCompilerTests/test ;sbt-test/scripted scala2-compat/* ;stdlib-bootstrapped/test:run ;stdlib-bootstrapped-tasty-tests/test"
           ./project/scripts/cmdTests
           ./project/scripts/bootstrappedOnlyCmdTests
 

.github/workflows/scaladoc.yaml

@@ -68,7 +68,7 @@ jobs:
           PR_NUMBER: ${{ github.event.pull_request.number }}
         with:
           inlineScript: |
-            DOC_DEST=pr-${PR_NUMBER:-${GITHUB_REF##*/}}
+            DOC_DEST=$(echo pr-${PR_NUMBER:-${GITHUB_REF##*/}} | tr -d -c "[-A-Za-z0-9]")
             echo uplading docs to https://scala3doc.virtuslab.com/$DOC_DEST
             az storage container create --name $DOC_DEST --account-name scala3docstorage --public-access container
             az storage blob upload-batch -s scaladoc/output -d $DOC_DEST --account-name scala3docstorage

.gitignore

@@ -30,22 +30,6 @@ node_modules
 .metals/
 metals.sbt
 
-# Scala-IDE specific
-.scala_dependencies
-.cache
-.cache-main
-.cache-tests
-.classpath
-.project
-.settings
-classes/
-*/bin/
-
-# Dotty IDE
-/.dotty-ide-dev-port
-/.dotty-ide-artifact
-/.dotty-ide.json
-
 # idea
 .idea
 .idea_modules
@@ -79,12 +63,9 @@ compiler/test/debug/Gen.jar
 compiler/before-pickling.txt
 compiler/after-pickling.txt
 bench/compile.txt
-*.dotty-ide-version
-
-# The vscode app for testing
-vscode-dotty/.vscode-test
 
 community-build/scala3-bootstrapped.version
+community-build/sbt-injected-plugins
 community-build/sbt-dotty-sbt
 community-build/sbt-scalajs-sbt
 community-build/dotty-community-build-deps

.gitmodules

@@ -1,6 +1,3 @@
-[submodule "community-build/community-projects/algebra"]
-	path = community-build/community-projects/algebra
-	url = https://github.com/dotty-staging/algebra
 [submodule "community-build/community-projects/betterfiles"]
 	path = community-build/community-projects/betterfiles
 	url = https://github.com/dotty-staging/better-files
@@ -250,3 +247,6 @@
 [submodule "community-build/community-projects/scalacheck-forward-compat"]
 	path = community-build/community-projects/scalacheck-forward-compat
 	url = https://github.com/dotty-staging/scalacheck
+[submodule "community-build/community-projects/http4s"]
+	path = community-build/community-projects/http4s
+	url = https://github.com/dotty-staging/http4s.git

CONTRIBUTING.md

@@ -12,14 +12,12 @@ This is the process for committing code to the Scala project. There are of cours
     2. The ticket has been discussed and prioritized by the team.
 3. You should always perform your work in its own Git branch. The branch should be given a descriptive name that explains its intent. Some teams also like adding the ticket number and/or the [GitHub](http://github.com) user ID to the branch name, these details is up to each of the individual teams. (See below for more details on branch naming.)
 4. When the feature or fix is completed you should open a [Pull Request](https://help.github.com/articles/using-pull-requests) on GitHub.
-5. The Pull Request should be reviewed by other maintainers (as many as feasible/practical). Note that a reviewer can also be an outside contributor—members of Typesafe and independent contributors are encouraged to participate in the review process. It is not a closed process. Please try to avoid conflict of interest—the spirit of the review process is to evenly distribute the understanding of our code base across its maintainers as well as to load balance quality assurance. Assigning a review to a "sure win" reviewer is not a good long-term solution.
+5. The Pull Request should be reviewed by other maintainers (as many as feasible/practical). Note that a reviewer can also be an outside contributor—members of Typesafe  or VirtusLab and independent contributors are encouraged to participate in the review process. It is not a closed process. Please try to avoid conflict of interest—the spirit of the review process is to evenly distribute the understanding of our code base across its maintainers as well as to load balance quality assurance. Assigning a review to a "sure win" reviewer is not a good long-term solution.
 6. After the review, you should resolve issues brought up by the reviewers as needed (pushing a new commit to address reviewers' comments), iterating until the reviewers give their thumbs up, the "LGTM" (acronym for "Looks Good To Me").
 7. Once the code has passed review the Pull Request can be merged into the distribution.
 
 ## Pull Request Requirements
 
-First, please have a look at and follow the [Pull Request Policy](https://github.com/scala/scala/wiki/Pull-Request-Policy) for guidelines on submitting a pull request to the dotty project. (the pull request policy is the same as for the Scala programming language)
-
 In order for a Pull Request to be considered, it has to meet these requirements:
 
 1. Live up to the current code standard:
@@ -39,7 +37,7 @@ All contributed code should come accompanied by documentation. Pull requests con
 
 It is ok to work on a public feature branch in the GitHub repository. Something that can sometimes be useful for early feedback etc. If so, then it is preferable to name the branch accordingly. This can be done by either prefixing the name with ``wip-`` as in ‘Work In Progress’, or use hierarchical names like ``wip/..``, ``feature/..`` or ``topic/..``. Either way is fine as long as it is clear that it is work in progress and not ready for merge. This work can temporarily have a lower standard. However, to be merged into master it will have to go through the regular process outlined above, with Pull Request, review etc..
 
-Also, to facilitate both well-formed commits and working together, the ``wip`` and ``feature``/``topic`` identifiers also have special meaning.   Any branch labelled with ``wip`` is considered “git-unstable” and may be rebased and have its history rewritten.   Any branch with ``feature``/``topic`` in the name is considered “stable” enough for others to depend on when a group is working on a feature.
+Also, to facilitate both well-formed commits and working together, the ``wip`` and ``feature``/``topic`` identifiers also have special meaning. Any branch labeled with ``wip`` is considered “git-unstable” and may be rebased and have its history rewritten.   Any branch with ``feature``/``topic`` in the name is considered “stable” enough for others to depend on when a group is working on a feature.
 
 ## Creating Commits And Writing Commit Messages
 
@@ -60,4 +58,3 @@ Example:
       - Details 1
       - Details 2
       - Details 3
-

MAINTENANCE.md

@@ -1,8 +1,8 @@
-# Issue Tsar Role
-This document formally defines the Issue Tsar role. This is a repository maintenance role that is assigned to core contributors on rotating basis.
+# Issue Supervisor Role
+This document formally defines the _Issue Supervisor_ role. This is a repository maintenance role that is assigned to core contributors on rotating basis.
 
 ## Responsibilities
-Issue Tsar is responsible for:
+Issue supervisor is responsible for:
 - Health of the CI, nightly releases and benchmark infrastructure.
 - PRs of external contributors: assigning someone to review, or handling themselves.
 - Triaging issues (especially new):
@@ -13,47 +13,48 @@ Issue Tsar is responsible for:
     - Attempting to reproduce the issue (or label “stat:cannot reproduce”)
     - Further minimizing the issue or asking the reporter of the issue to minimize it correctly (or label “stat:needs minimization”)
 
-Other core teammates are responsible for providing information to the Issue Tsar in a timely manner when it is requested if they have that information.
+Other core teammates are responsible for providing information to the issue supervisor in a timely manner when it is requested if they have that information.
 
 ## Assignment
-Issue Tsar is appointed for 7 days and is responsible for what is specified in the “Responsibilities” section during those 7 days. Their assumption of the role starts from the Dotty Meeting on Monday and ends on the next Dotty Meeting on Monday.
+Issue supervisor is appointed for 7 days and is responsible for what is specified in the “Responsibilities” section during those 7 days. Their assumption of the role starts from the Dotty Meeting on Monday and ends on the next Dotty Meeting on Monday.
 
-During the Dotty Meeting, an Issue Tsar is assigned for the current week and for the week after that.
+During the Dotty Meeting, an issue supervisor is assigned for the current week and for the week after that.
 
-Issue Tsardom schedule is maintained in the [Issue Tsardom Statistics spreadsheet](https://docs.google.com/spreadsheets/d/19IAqNzHfJ9rsii3EsjIGwPz5BLTFJs_byGM3FprmX3E/edit?usp=sharing). So, someone who knows their availability several weeks ahead into the future can assign themselves to be an issue tsar well ahead of time.
+Issue supervisor schedule is maintained in the [Issue Supervisor Statistics spreadsheet](https://docs.google.com/spreadsheets/d/19IAqNzHfJ9rsii3EsjIGwPz5BLTFJs_byGM3FprmX3E/edit?usp=sharing). So, someone who knows their availability several weeks ahead into the future can assign themselves to be an issue supervisor well ahead of time.
 
 ## Prerequisites
-An issue tsar needs to have all the accesses and privileges required to get their job done. This might include:
+An issue supervisor needs to have all the accesses and privileges required to get their job done. This might include:
 - Admin rights in lampepfl/dotty repository
 - Admin rights in lampepfl/dotty-feature-requests repository
 - Permissions to create new repositories in lampepfl organization (needed to fork repositories for the community build)
 - Access to the LAMP slack to be able to ask for help with the infrastructure, triaging and such
 
 ## Procedures
-To ensure proper health of the infrastructure, the Tsar regularly monitors its proper operation. If a malfunction is detected, the Tsar's job is to ensure that someone is working on it (or solve it on their own).
+To ensure proper health of the infrastructure, the supervisor regularly monitors its proper operation. If a malfunction is detected, the supervisor's job is to ensure that someone is working on it (or solve it on their own).
 
-If it is unclear what area an issue belongs to, the Tsar asks for advice from other team members on Slack or GitHub. If, after asking for advice, it turns out that nobody in the team knows how to classify it, the issue must be classified with a “stat:needs triage” label.
+If it is unclear what area an issue belongs to, the supervisor asks for advice from other team members on Slack or GitHub. If, after asking for advice, it turns out that nobody in the team knows how to classify it, the issue must be classified with a “stat:needs triage” label.
 
-If it is unclear who should review an external PR, the Tsar asks for advice from the rest of the core team. If after asking for advice, it is still unclear who should do it, the reviewer for such a PR will be decided at the next Dotty meeting.
+If it is unclear who should review an external PR, the supervisor asks for advice from the rest of the core team. If after asking for advice, it is still unclear who should do it, the reviewer for such a PR will be decided at the next Dotty meeting.
 
-In general, if anything else is unclear for proper fulfillment of responsibilities, the Tsar must proactively seek advice from other team members on Slack or other channels.
+In general, if anything else is unclear for proper fulfillment of responsibilities, the supervisor must proactively seek advice from other team members on Slack or other channels.
 
 ## Reporting
-At the end of their Tsardom, the Tsar reports to the team during the Dotty meeting on the following points:
+At the end of their supervision period, the supervisor reports to the team during the Dotty meeting on the following points:
 
 - Whether there were any incidents with the CI, nightlies and benchmarks, how they were resolved and what steps were taken to prevent them from happening in the future.
 - How many new external contributors’ PRs were there and what they were about (in brief).
-- How many new issues were opened during their Tsardom period? Were there any areas that got a lot of issues? How many regressions from a prior Scala 3 release were there? Which were designated for an MSc project or an Issue Spree?
-- If new labels were created or old ones were removed, or there is any other feedback on how to improve the Tsardom, mention that.
+- How many new issues were opened during their supervision period? Were there any areas that got a lot of issues? How many regressions from a prior Scala 3 release were there? Which were designated for an MSc project or an Issue Spree?
+- If new labels were created or old ones were removed, or there is any other feedback on how to improve the issue supervision, mention that.
 - Unassigned PRs and issues that the team failed to classify: bring them one by one so that the team can make a decision on them.
 
 # Maintenance List
-The following is the list of all the principal areas of the compiler and the core teams members who are responsible for their maintenance:
+The following is the list of all the principal areas of the compiler and the core team members who are responsible for their maintenance:
 
+- Parser: @odersky
 - Typer: @odersky, @smarter, (@dwijnand)
 - Erasure: @smarter, @odersky
 - Enums: @bishabosha
-- Export: @bishabosha, @odersky 
+- Export: @bishabosha, @odersky
 - Pattern Matching: @dwijnand, (@liufengyun), @sjrd
 - Inline: @nicolasstucki, @odersky
 - Metaprogramming (Quotes, Reflect, Staging): @nicolasstucki, @aherlihy

README.md

@@ -3,12 +3,11 @@ Dotty
 [![Dotty CI](https://github.com/lampepfl/dotty/workflows/Dotty/badge.svg?branch=master)](https://github.com/lampepfl/dotty/actions?query=branch%3Amain)
 [![Join the chat at https://discord.com/invite/scala](https://img.shields.io/discord/632150470000902164)](https://discord.com/invite/scala)
 
-* [Homepage](https://dotty.epfl.ch)
-* [Documentation](https://dotty.epfl.ch/docs)
+* [Documentation](https://docs.scala-lang.org/scala3/)
 
 Try it out
 ==========
-To try it in your project see also the [Getting Started User Guide](https://dotty.epfl.ch/#getting-started).
+To try it in your project see also the [Getting Started User Guide](https://docs.scala-lang.org/scala3/getting-started.html).
 
 Building a Local Distribution
 =============================
@@ -23,7 +22,7 @@ other more direct lines of communication such as email.
 
 How to Contribute
 =================
-* [Getting Started as Contributor](https://dotty.epfl.ch/docs/contributing/getting-started.html)
+* [Getting Started as Contributor](https://docs.scala-lang.org/scala3/guides/contribution/contribution-intro.html)
 * [Issues](https://github.com/lampepfl/dotty/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22)
 
 License

build.sbt

@@ -33,7 +33,6 @@ val sjsJUnitTests = Build.sjsJUnitTests
 val sjsCompilerTests = Build.sjsCompilerTests
 
 val `sbt-test` = Build.`sbt-test`
-val `vscode-dotty` = Build.`vscode-dotty`
 
 inThisBuild(Build.thisBuildSettings)
 inScope(Global)(Build.globalSettings)