Merge remote-tracking branch 'upstream/main' into warn-value-discard

Author: cb372

.github/workflows/ci.yaml

@@ -2,13 +2,9 @@ name: Dotty
 
 on:
   push:
-    branches-ignore:
-      - 'language-reference-stable'
     tags:
       - '**'
   pull_request:
-    branches-ignore:
-      - 'language-reference-stable'
   schedule:
     - cron: '0 3 * * *'  # Every day at 3 AM
   workflow_dispatch:
@@ -256,6 +252,7 @@ jobs:
            github.event_name == 'pull_request'
            && !contains(github.event.pull_request.body, '[skip ci]')
            && !contains(github.event.pull_request.body, '[skip community_build]')
+           && !contains(github.event.pull_request.body, '[skip community_build_a]')
          )
          || (
            github.event_name == 'workflow_dispatch'
@@ -303,6 +300,7 @@ jobs:
            github.event_name == 'pull_request'
            && !contains(github.event.pull_request.body, '[skip ci]')
            && !contains(github.event.pull_request.body, '[skip community_build]')
+           && !contains(github.event.pull_request.body, '[skip community_build_b]')
          )
          || (
            github.event_name == 'workflow_dispatch'
@@ -350,6 +348,7 @@ jobs:
            github.event_name == 'pull_request'
            && !contains(github.event.pull_request.body, '[skip ci]')
            && !contains(github.event.pull_request.body, '[skip community_build]')
+           && !contains(github.event.pull_request.body, '[skip community_build_c]')
          )
          || (
            github.event_name == 'workflow_dispatch'

.github/workflows/cla.yml

@@ -1,9 +1,11 @@
 name: Scala CLA
 on:
   pull_request:
+    branches-ignore:
+      - 'language-reference-stable'
   push:
     branches:
-      - 'language-reference-backport'
+      - 'language-reference-stable'
 permissions:
   contents: write
   pull-requests: write

.github/workflows/language-reference.yaml

@@ -1,4 +1,4 @@
-name: language-reference-documentation
+name: Language reference documentation
 
 on:
   push:
@@ -14,14 +14,14 @@ permissions:
 
 jobs:
   build-and-push:
+    name: Build reference documentation and push it
     permissions:
       contents: write  # for Git to git push
-      pull-requests: write  # for peter-evans/create-pull-request to create a PR
     runs-on: ubuntu-latest
     steps:
       - name: Get current date
         id: date
-        run: echo "::set-output name=date::$(date +'%Y-%m-%d')"
+        run: echo "date=$(date +'%Y-%m-%d')" >> $GITHUB_OUTPUT
 
       - name: Git Checkout
         uses: actions/checkout@v3
@@ -67,26 +67,22 @@ jobs:
           fi
           cd ..
 
-      - name: Merge changes to main
-        if: github.event_name == 'push'
-        run: |
-          cd dotty
-          git fetch origin main:main
-          git checkout main
-          git config user.name gh-actions
-          git config user.email [email protected]
-          git merge language-reference-stable
-          cd ..
-
-      - name: Create pull request with backport to main
-        if: github.event_name == 'push'
-        uses: peter-evans/create-pull-request@v4
+  backport-to-main:
+    name: Create pull request with backport to main
+    permissions:
+      pull-requests: write  # for repo-sync/pull-request to create a PR
+    runs-on: ubuntu-latest
+    if: github.event_name == 'push' || github.event_name == 'workflow_dispatch'
+    steps:
+      - uses: actions/checkout@v3
+      - uses: repo-sync/pull-request@v2
         with:
-          path: dotty
-          branch: language-reference-backport
-          labels: area:documentation
-          title: Backport changes from stable documentation branch
-          body: This pull request is created automatically after push to stable documentation branch and backports the changes
-          reviewers: pikinier20,julienrf
-          assignees: pikinier20
+          destination_branch: main
+          pr_label: area:documentation
+          pr_title: Sync with the stable documentation branch
+          pr_body: |
+            This pull request is syncing the main with changes from language-reference-stable.
+
+            It was created automatically after ${{ github.event.head_commit.id }} by @${{ github.event.head_commit.author.username }}
+          pr_assignee: ${{ github.event.head_commit.author.username }}
 

MAINTENANCE.md

@@ -1,9 +1,12 @@
 # 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.
+
+This document formally defines the _Issue Supervisor_ role. This is a repository maintenance role that is assigned to core contributors on a rotating basis.
 
 ## Responsibilities
-Issue supervisor is responsible for:
-- Health of the CI, nightly releases and benchmark infrastructure.
+
+The issue supervisor is responsible for:
+
+- The health of the CI, nightly releases and benchmark infrastructure.
 - PRs of external contributors: assigning someone to review, or handling themselves.
 - Triaging issues (especially new):
   - Each issue needs to be assigned an `itype` and 1 or more `area` labels.
@@ -12,42 +15,50 @@ Issue supervisor is responsible for:
   - Modifying issue labels to best capture information about the issues
     - 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”)
+  - Identifying which issues are of considerable importance and bringing them to the attention of the team during the Dotty meeting, where they can be filtered and added to the [Future Versions](https://github.com/lampepfl/dotty/milestone/46) milestone.
 
 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 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.
+
+The 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 supervisor is assigned for the current week and for the week after that.
 
-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.
+The 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 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)
+- Permission 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 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).
+
+To ensure the 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 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 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 supervisor must proactively seek advice from other team members on Slack or other channels.
+In general, if anything else is unclear for the 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 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 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.
+- Issues of importance – candidates for the Future Versions milestone.
+
+## Maintenance List
 
-# Maintenance List
 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
@@ -73,5 +84,5 @@ The following is the list of all the principal areas of the compiler and the cor
 - Vulpix: @dwijnand, @prolativ
 - JVM backend: @Kordyjan, (@sjrd)
 - Derivation & Mirrors: @bishabosha, (@dwijnand)
-- Linting (especially unused warnings) / Reporting UX  : VirtusLab TBD?
+- Linting (especially unused warnings) / Reporting UX: VirtusLab TBD?
 - Java-compat: @Kordyjan

community-build/community-projects/betterfiles

@@ -140,7 +140,7 @@ final case class SbtCommunityProject(
       case Some(ivyHome) => List(s"-Dsbt.ivy.home=$ivyHome")
       case _ => Nil
     extraSbtArgs ++ sbtProps ++ List(
-      "-sbt-version", "1.7.1",
+      "-sbt-version", "1.8.0",
       "-Dsbt.supershell=false",
       s"-Ddotty.communitybuild.dir=$communitybuildDir",
       s"--addPluginSbtFile=$sbtPluginFilePath"