Merge branch 'main' into implement/Xlint/shadow_warnings

Author: schuetzcarl

.github/ISSUE_TEMPLATE/feature.md

@@ -1,10 +1,10 @@
 ---
 name: "\U0001F389 Suggest a feature"
-about: Please create a feature request here https://github.com/lampepfl/dotty-feature-requests
+about: Please create a feature request here https://github.com/lampepfl/dotty/discussions/new?category=feature-requests
 title: ''
 labels: ''
 assignees: ''
 
 ---
 
-Please create a feature request here: [lampepfl/dotty-feature-requests](https://github.com/lampepfl/dotty-feature-requests).
+Please create a feature request in the [Dotty Discussions](https://github.com/lampepfl/dotty/discussions/new?category=feature-requests).

.gitignore

@@ -95,3 +95,7 @@ contributors.js
 content-contributors.css
 docs/_spec/_site/
 docs/_spec/.jekyll-metadata
+
+# scaladoc related
+scaladoc/output/
+

.gitmodules

@@ -21,7 +21,7 @@
 	url = https://github.com/dotty-staging/fastparse
 [submodule "community-build/community-projects/stdLib213"]
 	path = community-build/community-projects/stdLib213
-	url = https://github.com/dotty-staging/scala
+	url = https://github.com/dotty-staging/scala213
 [submodule "community-build/community-projects/sourcecode"]
 	path = community-build/community-projects/sourcecode
 	url = https://github.com/dotty-staging/sourcecode

.vscode-template/settings.json

@@ -9,6 +9,7 @@
     "**/*.class": true,
     "**/*.tasty": true,
     "**/target/": true,
-    "community-build/community-projects": true
+    "community-build/community-projects": true,
+    "tests/pos-with-compiler-cc/dotc/**/*.scala": true
   }
 }

MAINTENANCE.md

@@ -16,6 +16,11 @@ The issue supervisor 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”)
   - 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.
+  - Identifying if a report is really a feature request and if so, converting it to
+    a [feature request discussion](https://github.com/lampepfl/dotty/discussions/categories/feature-requests).
+- Keeping an eye on new
+[discussions](https://github.com/lampepfl/dotty/discussions), making sure they
+don't go unanswered and also correctly labeling new feature requests.
 
 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.
 
@@ -32,7 +37,6 @@ The issue supervisor schedule is maintained in the [Issue Supervisor Statistics
 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
 - 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
 

community-build/README.md

@@ -1,75 +1,5 @@
 # Scala 3 Community Build
 
-This project contains tests to build and test a corpus of open sources Scala
-projects against the latest version of Scala 3.
-
-## Running it locally
-
-To run the community build on a local machine, first fetch all the git
-submodules with `git submodule update --init` and run `sbt community-build/test`
-from the root of the dotty repo.
-
-To run a single project, you can use the usual syntax for running a single JUnit
-test, for example `community-build/testOnly -- *shapeless`
-
-In CI the community build is split up into 3 seperate groups: A, B, and C. To
-run one specific build you can also use the same JUnit syntax as above targeting
-the individual group. For example:
-
-```
-sbt "community-build/testOnly dotty.communitybuild.CommunityBuildTestA"
-```
-
-## Adding your project
-
-The community build is able to handle both Mill and sbt projects. To add your
-project to the community build you can follow these steps:
-
-1. Ensure your project is compiling with Scala 3. If you need help make sure to
-   check out the [Scala 3 Migration
-   Guide](https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html).
-   You can see the submodules in
-   [community-projects](https://github.com/lampepfl/dotty/tree/main/community-build/community-projects/)
-   for examples of projects that compile with Scala 3.
-
-2. Open a PR against this repo that:
-     - Adds your project as a new git submodule
-       - `git submodule add https://github.com/dotty-staging/XYZ.git community-build/community-projects/XYZ`
-     - Add the project to [projects.scala](https://github.com/lampepfl/dotty/blob/main/community-build/src/scala/dotty/communitybuild/projects.scala)
-     - Adds a test in [CommunityBuildTest.scala](https://github.com/lampepfl/dotty/blob/main/community-build/test/scala/dotty/communitybuild/CommunityBuildTest.scala)
-
-3. Once the CI is green, someone from the Dotty team will fork your repo and add
-   it to [dotty-staging](https://github.com/dotty-staging). This enables us to
-   make changes to your fork if necessary to keep the community build running
-   smoothly.
-
-4. Once the fork is created, please update your PR to point to this new fork
-   instead of your repo.
-
-## Updating a project
-
-The projects included in the community build are all forked and located in
-[dotty-staging](https://github.com/dotty-staging). When something needs to be
-bumped the process is as follows:
-
-1. Fork the dotty staging repo and sync it with the upstream project.
-
-2. Once you've verified that the tests are all passing you can then either
-   request in your PR that the dotty-staging fork be synced or in the
-   [scala-contributors](https://discord.com/channels/632150470000902164/632628489719382036)
-   discord channel.
-
-### Some helpful tips
-
-- If you're unfamiliar with Git Submodules you can find a nice guide to get
-    familiar with them [here](https://git-scm.com/book/en/v2/Git-Tools-Submodules).
-- Keep in mind that many projects are interrelated. So when you bump one that
-    change may cascade through multiple different projects causing you to have
-    to bump multiple. Plan accordingly and at times it's best to pin it to a
-    stable release version, especially if it's a root library that many others
-    in the community build are relying on.
-
-## Looking for the "unmanaged" Scala 3 community build?
-
-You can find this [here](https://github.com/VirtusLab/community-build3).
-
+For information on the community build check out the [Community Build section of
+the Contributing
+Docs](https://dotty.epfl.ch/docs/contributing/community-build.html).

community-build/community-projects/munit

@@ -811,12 +811,13 @@ object desugar {
                     // TODO: drop this once we do not silently insert empty class parameters anymore
           case paramss => paramss
         }
+        val finalFlag = if ctx.settings.Yscala2Stdlib.value then EmptyFlags else Final
         // implicit wrapper is typechecked in same scope as constructor, so
         // we can reuse the constructor parameters; no derived params are needed.
         DefDef(
           className.toTermName, joinParams(constrTparams, defParamss),
           classTypeRef, creatorExpr)
-          .withMods(companionMods | mods.flags.toTermFlags & (GivenOrImplicit | Inline) | Final)
+          .withMods(companionMods | mods.flags.toTermFlags & (GivenOrImplicit | Inline) | finalFlag)
           .withSpan(cdef.span) :: Nil
       }