Merge branch 'main' into fix-conflicts-stable

Author: bishabosha

.github/PULL_REQUEST_TEMPLATE/fix-issue.md

@@ -6,14 +6,14 @@ assignees: ''
 
 ---
 
-<!-- 
-  TODO first sign the CLA 
+<!--
+  TODO first sign the CLA
   https://www.lightbend.com/contribute/cla/scala
 -->
 
 ## Fix #XYZ
 
-<!-- TODO description of the change --> 
+<!-- TODO description of the change -->
 
 
 <!-- Ideally should have a called "Fix #XYZ: A SHORT FIX DESCRIPTION" -->

.github/PULL_REQUEST_TEMPLATE/other-pr.md

@@ -6,14 +6,14 @@ assignees: ''
 
 ---
 
-<!-- 
-  TODO first sign the CLA 
+<!--
+  TODO first sign the CLA
   https://www.lightbend.com/contribute/cla/scala
 -->
 
 ## Description
 
-<!-- TODO description of the change --> 
+<!-- TODO description of the change -->
 
 
 <!-- Ideally should have a single commit -->

.github/workflows/ci.yaml

@@ -2,9 +2,24 @@ name: Dotty
 
 on:
   push:
+    ## Be careful if you add or remove something here! Quoting from
+    ## <https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore>:
+    ##
+    ## > If you define only tags/tags-ignore or only branches/branches-ignore, the
+    ## > workflow won't run for events affecting the undefined Git ref. If you
+    ## > define neither tags/tags-ignore or branches/branches-ignore, the workflow
+    ## > will run for events affecting either branches or tags.
+    ##
+    ## We want the CI to run on both branches and tags, so we should either have:
+    ## - both (tags or tags-ignore) and (branches or branches-ignore),
+    ## - or neither of them.
+    ## But it's important to not have only one or the other.
     tags:
-      - '**'
+      - '*'
+    branches-ignore:
+      - 'gh-readonly-queue/**'
   pull_request:
+  merge_group:
   schedule:
     - cron: '0 3 * * *'  # Every day at 3 AM
   workflow_dispatch:
@@ -87,6 +102,7 @@ jobs:
         - ${{ github.workspace }}/../../cache/general:/root/.cache
     if: "github.event_name == 'schedule' && github.repository == 'lampepfl/dotty'
          || github.event_name == 'push'
+         || github.event_name == 'merge_group'
          || (
            github.event_name == 'pull_request'
            && !contains(github.event.pull_request.body, '[skip ci]')
@@ -132,6 +148,7 @@ jobs:
            github.event_name == 'push'
            && github.ref != 'refs/heads/main'
          )
+         || github.event_name == 'merge_group'
          || (
            github.event_name == 'pull_request'
            && !contains(github.event.pull_request.body, '[skip ci]')
@@ -208,6 +225,7 @@ jobs:
         - ${{ github.workspace }}/../../cache/general:/root/.cache
     if: "github.event_name == 'schedule' && github.repository == 'lampepfl/dotty'
          || github.event_name == 'push'
+         || github.event_name == 'merge_group'
          || (
            github.event_name == 'pull_request'
            && !contains(github.event.pull_request.body, '[skip ci]')
@@ -248,6 +266,7 @@ jobs:
         - ${{ github.workspace }}/../../cache/general:/root/.cache
     if: "github.event_name == 'schedule' && github.repository == 'lampepfl/dotty'
          || github.event_name == 'push'
+         || github.event_name == 'merge_group'
          || (
            github.event_name == 'pull_request'
            && !contains(github.event.pull_request.body, '[skip ci]')
@@ -296,6 +315,7 @@ jobs:
         - ${{ github.workspace }}/../../cache/general:/root/.cache
     if: "github.event_name == 'schedule' && github.repository == 'lampepfl/dotty'
          || github.event_name == 'push'
+         || github.event_name == 'merge_group'
          || (
            github.event_name == 'pull_request'
            && !contains(github.event.pull_request.body, '[skip ci]')
@@ -344,6 +364,7 @@ jobs:
         - ${{ github.workspace }}/../../cache/general:/root/.cache
     if: "github.event_name == 'schedule' && github.repository == 'lampepfl/dotty'
          || github.event_name == 'push'
+         || github.event_name == 'merge_group'
          || (
            github.event_name == 'pull_request'
            && !contains(github.event.pull_request.body, '[skip ci]')
@@ -575,45 +596,6 @@ jobs:
           external_repository: lampepfl/dotty-website
           publish_branch: gh-pages
 
-  nightly_unmanaged_community_build:
-    # Self-hosted runner is used only for getting current build version
-    runs-on: [self-hosted, Linux]
-    container:
-      image: lampepfl/dotty:2021-03-22
-      options: --cpu-shares 4096
-      volumes:
-        - ${{ github.workspace }}/../../cache/sbt:/root/.sbt
-        - ${{ github.workspace }}/../../cache/ivy:/root/.ivy2/cache
-        - ${{ github.workspace }}/../../cache/general:/root/.cache
-    needs: [publish_nightly]
-    if: "(github.event_name == 'schedule' || github.event_name == 'workflow_dispatch') && github.repository == 'lampepfl/dotty'"
-    env:
-      NIGHTLYBUILD: yes
-    steps:
-      - name: Reset existing repo
-        run: git -c "http.https://github.com/.extraheader=" fetch --recurse-submodules=no "https://github.com/lampepfl/dotty" && git reset --hard FETCH_HEAD || true
-
-      - name: Checkout cleanup script
-        uses: actions/checkout@v3
-
-      - name: Cleanup
-        run: .github/workflows/cleanup.sh
-
-      - name: Git Checkout
-        uses: actions/checkout@v3
-
-      - name: Add SBT proxy repositories
-        run: cp -vf .github/workflows/repositories /root/.sbt/ ; true
-
-      - name: Get version string for this build
-        run: |
-          ver=$(./project/scripts/sbt "print scala3-compiler-bootstrapped/version" | tail -n1)
-          echo "This build version: $ver"
-          echo "THISBUILD_VERSION=$ver" >> $GITHUB_ENV
-      # Steps above are copy-pasted from publish_nightly, needed only to resolve THISBUILD_VERSION
-      - name: Trigger unmanaged community build
-        run: .github/workflows/scripts/triggerUnmanagedCommunityBuild.sh "${{ secrets.BUILD_TOKEN }}" "$THISBUILD_VERSION"
-
   publish_release:
     permissions:
       contents: write  # for actions/create-release to create a release

.github/workflows/cla.yml

@@ -6,6 +6,7 @@ on:
   push:
     branches:
       - 'language-reference-stable'
+  merge_group:
 permissions:
   contents: write
   pull-requests: write

.github/workflows/releases.yml

@@ -13,9 +13,9 @@ jobs:
       options: --cpu-shares 4096
 
     env:
-      SDKMAN_KEY: ${{ secrets.SDKMAN_KEY }} 
+      SDKMAN_KEY: ${{ secrets.SDKMAN_KEY }}
       SDKMAN_TOKEN: ${{ secrets.SDKMAN_TOKEN }}
-      
+
     steps:
       - name: Reset existing repo
         run: git -c "http.https://github.com/.extraheader=" fetch --recurse-submodules=no "https://github.com/lampepfl/dotty" && git reset --hard FETCH_HEAD || true

.github/workflows/scaladoc.yaml

@@ -4,9 +4,11 @@ on:
   push:
     branches-ignore:
       - 'language-reference-stable'
+      - 'gh-readonly-queue/**'
   pull_request:
     branches-ignore:
       - 'language-reference-stable'
+  merge_group:
 permissions:
   contents: read
 
@@ -15,7 +17,8 @@ jobs:
     env:
       AZURE_STORAGE_SAS_TOKEN: ${{ secrets.AZURE_STORAGE_SAS_TOKEN }}
     runs-on: ubuntu-latest
-    if: "(    github.event_name == 'pull_request'
+    if: "github.event_name == 'merge_group'
+         || (    github.event_name == 'pull_request'
            && !contains(github.event.pull_request.body, '[skip ci]')
            && !contains(github.event.pull_request.body, '[skip docs]')
          )

.github/workflows/scripts/publish-sdkman.sh

@@ -9,11 +9,11 @@
 
 set -u
 
-# latest stable dotty version 
+# latest stable dotty version
 DOTTY_VERSION=$(curl -s https://api.github.com/repos/lampepfl/dotty/releases/latest  | grep '"tag_name":' | sed -E 's/.*"([^"]+)".*/\1/')
 DOTTY_URL="https://github.com/lampepfl/dotty/releases/download/$DOTTY_VERSION/scala3-$DOTTY_VERSION.zip"
 
-# checking if dotty version is available 
+# checking if dotty version is available
 if ! curl --output /dev/null --silent --head --fail "$DOTTY_URL"; then
   echo "URL doesn't exist: $DOTTY_URL"
   exit 1

.github/workflows/scripts/triggerUnmanagedCommunityBuild.sh

@@ -35,6 +35,9 @@ metals.sbt
 .idea_modules
 /.worksheet/
 
+# scala-cli
+.scala-build
+
 # Partest
 dotty.jar
 dotty-lib.jar
@@ -90,3 +93,5 @@ compiler/test-coursier/run/*.jar
 # docs related
 contributors.js
 content-contributors.css
+docs/_spec/_site/
+docs/_spec/.jekyll-metadata

.gitignore

@@ -1,60 +1,5 @@
-# Dotty Developer Guidelines
+# Contributing to Dotty
 
-These guidelines are meant to be a living document that should be changed and adapted as needed. We encourage changes that make it easier to achieve our goals in an efficient way.
-
-## General Workflow
-
-This is the process for committing code to the Scala project. There are of course exceptions to these rules, for example minor changes to comments and documentation, fixing a broken build etc.
-
-1. Make sure you have signed the [Scala CLA](https://www.lightbend.com/contribute/cla/scala), if not, sign it.
-2. Before starting to work on a feature or a fix, it's good practice to ensure that:
-    1. There is a ticket for your work in the project's [issue tracker](https://github.com/lampepfl/dotty/issues);
-    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  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
-
-In order for a Pull Request to be considered, it has to meet these requirements:
-
-1. Live up to the current code standard:
-   - Not violate [DRY](https://www.oreilly.com/library/view/97-things-every/9780596809515/ch30.html).
-   - [Boy Scout Rule](https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html) should be applied.
-2. Tests are of paramount importance.
-3. The code must be well documented in the project's standard documentation format (see the ‘Documentation’ section below).
-
-If *all* of these requirements are not met then the code should **not** be merged into the distribution, and need not even be reviewed.
-
-## Documentation
-
-All contributed code should come accompanied by documentation. Pull requests containing undocumented code will not be accepted. Both user-facing Scaladoc comments, as well as committer-facing internal documentation (i.e. essential design decisions that other maintainers should know about should be placed inline with line comments `//`) should be accompanying all contributed code where possible.
-
-
-## Work In Progress
-
-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 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
-
-Follow these guidelines when creating public commits and writing commit messages.
-
-1. If your work spans multiple local commits (for example; if you do safe point commits while working in a feature branch or work in a branch for long time doing merges/rebases etc.) then please do not commit it all but rewrite the history by squashing the commits into one large commit which is accompanied by a detailed commit message for (as discussed in the following sections). For more info, see the article: [Git Workflow](http://sandofsky.com/blog/git-workflow.html). Additionally, every commit should be able to be used in isolation—that is, each commit must build and pass all tests.
-2. The first line should be a descriptive sentence about what the commit is doing. It should be possible to fully understand what the commit does by just reading this single line. It is **not ok** to only list the ticket number, type "minor fix" or similar. If the commit has a corresponding ticket, include a reference to the ticket number, prefixed with "Closes #", at the beginning of the first line followed by the title of the ticket, assuming that it aptly and concisely summarizes the commit in a single line. If the commit is a small fix, then you are done. If not, go to 3.
-3. Following the single line description (ideally no more than 70 characters long) should be a blank line followed by an enumerated list with the details of the commit.
-4. Add keywords for your commit (depending on the degree of automation we reach, the list may change over time):
-    * ``Review by @githubuser`` - will notify the reviewer via GitHub. Everyone is encouraged to give feedback, however. (Remember that @-mentions will result in notifications also when pushing to a WIP branch, so please only include this in your commit message when you're ready for your pull request to be reviewed. Alternatively, you may request a review in the pull request's description.)
-    * ``Fix/Fixing/Fixes/Close/Closing/Refs #ticket`` - if you want to mark the ticket as fixed in the issue tracker (Assembla understands this).
-    * ``backport to _branch name_`` - if the fix needs to be cherry-picked to another branch (like 2.9.x, 2.10.x, etc)
-
-Example:
-
-    Closes #2 Fixes the build
-
-      - Details 1
-      - Details 2
-      - Details 3
+Firstly, thanks for being willing to contribute to Dotty! Head on over the
+[Scala 3 Contributing
+Guide](https://docs.scala-lang.org/scala3/guides/contribution/contribution-intro.html), which should have all the info you're looking for.