Merge branch 'master' into master

.clangd

@@ -0,0 +1,2 @@
+CompileFlags:
+  Add: [-I., -I.., -Iflisp, -Isupport, -I../support, -I../usr/include, -I../../usr/include, -Wall,]

.git-blame-ignore-revs

@@ -5,3 +5,5 @@
 e66bfa5dd32f93e76068c00ad882c1fc839c5af8
 # whitespace: replace non-breaking space => space
 100a741e7ab38c91d48cc929bb001afc8e09261f
+# whitespace: replace tabs => space
+b03e8ab9c7bd3e001add519571858fa04d6a249b

.github/workflows/LabelCheck.yml

@@ -0,0 +1,19 @@
+name: Labels
+
+permissions:
+  contents: read
+on:
+  pull_request:
+    types: [labeled, unlabeled, opened, reopened, edited, synchronize]
+jobs:
+  enforce-labels:
+    name: Check for blocking labels
+    runs-on: ubuntu-latest
+    timeout-minutes: 2
+    steps:
+    - uses: yogevbd/[email protected]
+      with:
+        # REQUIRED_LABELS_ANY: "bug,enhancement,skip-changelog"
+        # REQUIRED_LABELS_ANY_DESCRIPTION: "Select at least one label ['bug','enhancement','skip-changelog']"
+        BANNED_LABELS: "needs docs,needs compat annotation,needs more info,needs nanosoldier run,needs news,needs pkgeval,needs tests,DO NOT MERGE"
+        BANNED_LABELS_DESCRIPTION: "A PR should not be merged with `needs *` or `DO NOT MERGE` labels"

.gitignore

@@ -33,7 +33,8 @@
 .DS_Store
 .idea/*
 .vscode/*
-
+*.heapsnapshot
+.cache
 # Buildkite: Ignore the entire .buildkite directory
 /.buildkite
 

.mailmap

@@ -283,3 +283,15 @@ Daniel Karrasch <[email protected]> <[email protected]>
 
 Roger Luo <[email protected]> <[email protected]>
 Roger Luo <[email protected]> <[email protected]>
+
+Frames Catherine White <[email protected]> <[email protected]>
+Frames Catherine White <[email protected]> <[email protected]>
+Frames Catherine White <[email protected]> <[email protected]>
+
+Claire Foster <[email protected]> <[email protected]>
+
+Jishnu Bhattacharya <[email protected]> <[email protected]>
+Jishnu Bhattacharya <[email protected]> <[email protected]>
+
+Shuhei Kadowaki <[email protected]> <[email protected]>
+Shuhei Kadowaki <[email protected]> <[email protected]>

CONTRIBUTING.md

@@ -58,9 +58,9 @@ A useful bug report filed as a GitHub issue provides information about how to re
 
 ### Writing tests
 
-There are never enough tests. Track [code coverage at Coveralls](https://coveralls.io/r/JuliaLang/julia), and help improve it.
+There are never enough tests. Track [code coverage at Codecov](https://codecov.io/github/JuliaLang/julia), and help improve it.
 
-1. Go visit https://coveralls.io/r/JuliaLang/julia.
+1. Go visit https://codecov.io/github/JuliaLang/julia.
 
 2. Browse through the source files and find some untested functionality (highlighted in red) that you think you might be able to write a test for.
 
@@ -74,7 +74,7 @@ There are never enough tests. Track [code coverage at Coveralls](https://coveral
 * You can see the current buildbot setup at: https://build.julialang.org/builders
 * [Issue 9493](https://github.com/JuliaLang/julia/issues/9493) and [issue 11885](https://github.com/JuliaLang/julia/issues/11885) have more detailed discussion on code coverage.
 
-Coveralls shows functionality that still needs "proof of concept" tests. These are important, as are tests for tricky edge cases, such as converting between integer types when the number to convert is near the maximum of the range of one of the integer types. Even if a function already has some coverage on Coveralls, it may still benefit from tests for edge cases.
+Code coverage shows functionality that still needs "proof of concept" tests. These are important, as are tests for tricky edge cases, such as converting between integer types when the number to convert is near the maximum of the range of one of the integer types. Even if a function already has some coverage on Codecov, it may still benefit from tests for edge cases.
 
 ### Improving documentation
 
@@ -269,7 +269,7 @@ Be sure to change the UUID value back before making the pull request.
 
 ### Contributing to patch releases
 
-The process of creating a patch release is roughly as follows:
+The process of [creating a patch release](https://docs.julialang.org/en/v1/devdocs/build/distributing/#Point-releasing-101) is roughly as follows:
 
 1. Create a new branch (e.g. `backports-release-1.6`) against the relevant minor release
    branch (e.g. `release-1.6`). Usually a corresponding pull request is created as well.
@@ -293,7 +293,7 @@ The process of creating a patch release is roughly as follows:
 6. Ping `@JuliaLang/releases` to tag the patch release and update the website.
 
 7. Open a pull request that bumps the version of the relevant minor release to the
-   next prerelase patch version, e.g. as in [this pull request](https://github.com/JuliaLang/julia/pull/37724).
+   next prerelease patch version, e.g. as in [this pull request](https://github.com/JuliaLang/julia/pull/37724).
 
 Step 2 above, i.e. backporting commits to the `backports-release-X.Y` branch, has largely
 been automated via [`Backporter`](https://github.com/KristofferC/Backporter): Backporter
@@ -325,7 +325,7 @@ please remove the `backport-X.Y` tag from the originating pull request for the c
  - use lower case with underscores for method names
  - it is generally preferred to use ASCII operators and identifiers over
    Unicode equivalents whenever possible
- - in docstring refer to the language as "Julia" and the executable as "`julia`"
+ - in docstrings refer to the language as "Julia" and the executable as "`julia`"
 
 #### General Formatting Guidelines For C code contributions
 
@@ -340,9 +340,8 @@ please remove the `backport-X.Y` tag from the originating pull request for the c
 ### Git Recommendations For Pull Requests
 
  - Avoid working from the `master` branch of your fork, creating a new branch will make it easier if Julia's `master` changes and you need to update your pull request.
- - Try to [squash](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html) together small commits that make repeated changes to the same section of code so your pull request is easier to review, and Julia's history won't have any broken intermediate commits. A reasonable number of separate well-factored commits is fine, especially for larger changes.
+ - Try to [squash](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html) together small commits that make repeated changes to the same section of code so your pull request is easier to review. A reasonable number of separate well-factored commits is fine, especially for larger changes.
  - If any conflicts arise due to changes in Julia's `master`, prefer updating your pull request branch with `git rebase` versus `git merge` or `git pull`, since the latter will introduce merge commits that clutter the git history with noise that makes your changes more difficult to review.
- - If you see any unrelated changes to submodules like `deps/libuv`, `deps/openlibm`, etc., try running `git submodule update` first.
  - Descriptive commit messages are good.
  - Using `git add -p` or `git add -i` can be useful to avoid accidentally committing unrelated changes.
  - When linking to specific lines of code in discussion of an issue or pull request, hit the `y` key while viewing code on GitHub to reload the page with a URL that includes the specific version that you're viewing. That way any lines of code that you refer to will still make sense in the future, even if the content of the file changes.
@@ -364,7 +363,7 @@ please remove the `backport-X.Y` tag from the originating pull request for the c
   - **Community:** <https://julialang.org/community/>
   - **Source code:** <https://github.com/JuliaLang/julia>
   - **Documentation:** <https://docs.julialang.org>
-  - **Code coverage:** <https://coveralls.io/r/JuliaLang/julia>
+  - **Code coverage:** <https://codecov.io/github/JuliaLang/julia>
 
 * Design of Julia
   - [Julia: A Fresh Approach to Numerical Computing](https://julialang.org/assets/research/julia-fresh-approach-BEKS.pdf)