[GHA] Unacceptable language check

# Motivation

Next up replacing part of our soundness script that checked for unacceptable language.

# Modification

This PR adds a new GH action that checks for unacceptable language.

# Result

One more script replaced

.github/workflows/reusable_pull_request.yml

@@ -3,18 +3,26 @@ name: Pull Request
 on:
   workflow_call:
     inputs:
-      enable_unit_tests:
+      unit_tests_enabled:
         type: boolean
         description: "Boolean to enable the unit tests job. Defaults to true."
         default: true
-      enable_api_breakage_check:
+      api_breakage_check_enabled:
         type: boolean
         description: "Boolean to enable the API breakage check job. Defaults to true."
         default: true
-      enable_docs_check:
+      docs_check_enabled:
         type: boolean
         description: "Boolean to enable the docs check job. Defaults to true."
         default: true
+      acceptable_language_check_enabled:
+        type: boolean
+        description: "Boolean to enable the acceptable language check job. Defaults to true."
+        default: true
+      acceptable_language_check_word_list:
+        type: string
+        description: "List of unacceptable words. Defaults to a sensitive list of words."
+        default: "blacklist whitelist slave master sane sanity insane insanity kill killed killing hang hung hanged hanging"
 
 ## We are cancelling previously triggered workflow runs
 concurrency:
@@ -24,7 +32,7 @@ concurrency:
 jobs:
   unit-tests:
     name: Unit tests
-    if: ${{ inputs.enable_unit_tests }}
+    if: ${{ inputs.unit_tests_enabled }}
     runs-on: ubuntu-latest
     strategy:
       fail-fast: false
@@ -46,7 +54,7 @@ jobs:
 
   api-breakage-check:
     name: API breakage check
-    if: ${{ inputs.enable_api_breakage_check }}
+    if: ${{ inputs.api_breakage_check_enabled }}
     runs-on: ubuntu-latest
     container:
       image: swift:5.10-noble
@@ -65,7 +73,7 @@ jobs:
 
   docs-check:
     name: Documentation check
-    if: ${{ inputs.enable_docs_check }}
+    if: ${{ inputs.docs_check_enabled }}
     runs-on: ubuntu-latest
     container:
       image: swift:5.10-noble
@@ -83,4 +91,39 @@ jobs:
 
         for target in "${targets[@]}"; do
           swift package plugin generate-documentation --target "$target" --warnings-as-errors --analyze --level detailed
-        done
+        done
+
+  acceptable-language-check:
+    name: Acceptable language check
+    if: ${{ inputs.acceptable_language_check_enabled }}
+    runs-on: ubuntu-latest
+    timeout-minutes: 1
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v4
+    - name: Run acceptable language check
+      shell: bash
+      env:
+        UNACCEPTABLE_LANGUAGE_PATTERNS: ${{ inputs.acceptable_language_check_word_list}}
+      run: |
+        set -euo pipefail
+
+        log() { printf -- "** %s\n" "$*" >&2; }
+        error() { printf -- "** ERROR: %s\n" "$*" >&2; }
+        fatal() { error "$@"; exit 1; }
+
+        test -n "${UNACCEPTABLE_LANGUAGE_PATTERNS:-}" || fatal "UNACCEPTABLE_LANGUAGE_PATTERNS unset"
+      
+        log "Checking for unacceptable language..."
+        UNACCEPTABLE_LANGUAGE_LINES=$(git -C . grep \
+          -w -i -I -o \
+          -H -n --column \
+          -E "${UNACCEPTABLE_LANGUAGE_PATTERNS// /|}" \
+          -- \
+          ":(exclude)\.github\/workflows\/reusable_pull_request\.yml"
+        ) || true | /usr/bin/paste -s -d " " -
+       
+        if [ -n "${UNACCEPTABLE_LANGUAGE_LINES}" ]; then
+          fatal " ❌ Found unacceptable language:
+        ${UNACCEPTABLE_LANGUAGE_LINES}"
+        fi

Sources/NIO/Docs.docc/index.md

@@ -128,7 +128,7 @@ One major difference between writing concurrent code and writing synchronous cod
 
 An [`EventLoopFuture<T>`][elf] is essentially a container for the return value of a function that will be populated *at some time in the future*. Each [`EventLoopFuture<T>`][elf] has a corresponding [`EventLoopPromise<T>`][elp], which is the object that the result will be put into. When the promise is succeeded, the future will be fulfilled.
 
-If you had to poll the future to detect when it completed that would be quite inefficient, so [`EventLoopFuture<T>`][elf] is designed to have managed callbacks. Essentially, you can hang callbacks off the future that will be executed when a result is available. The [`EventLoopFuture<T>`][elf] will even carefully arrange the scheduling to ensure that these callbacks always execute on the event loop that initially created the promise, which helps ensure that you don't need too much synchronization around [`EventLoopFuture<T>`][elf] callbacks.
+If you had to poll the future to detect when it completed that would be quite inefficient, so [`EventLoopFuture<T>`][elf] is designed to have managed callbacks. Essentially, you can chain callbacks off the future that will be executed when a result is available. The [`EventLoopFuture<T>`][elf] will even carefully arrange the scheduling to ensure that these callbacks always execute on the event loop that initially created the promise, which helps ensure that you don't need too much synchronization around [`EventLoopFuture<T>`][elf] callbacks.
 
 Another important topic for consideration is the difference between how the promise passed to `close` works as opposed to `closeFuture` on a [`Channel`][c]. For example, the promise passed into `close` will succeed after the [`Channel`][c] is closed down but before the [`ChannelPipeline`][cp] is completely cleared out. This will allow you to take action on the [`ChannelPipeline`][cp] before it is completely cleared out, if needed. If it is desired to wait for the [`Channel`][c] to close down and the [`ChannelPipeline`][cp] to be cleared out without any further action, then the better option would be to wait for the `closeFuture` to succeed.
 

Sources/NIOCore/SystemCallHelpers.swift

@@ -122,7 +122,7 @@ enum SystemCalls {
             let err = errno
 #endif
 
-            // There is really nothing "sane" we can do when EINTR was reported on close.
+            // There is really nothing "good" we can do when EINTR was reported on close.
             // So just ignore it and "assume" everything is fine == we closed the file descriptor.
             //
             // For more details see:

Sources/NIOPosix/System.swift

@@ -463,7 +463,7 @@ internal enum Posix {
             let err = errno
 #endif
 
-            // There is really nothing "sane" we can do when EINTR was reported on close.
+            // There is really nothing "good" we can do when EINTR was reported on close.
             // So just ignore it and "assume" everything is fine == we closed the file descriptor.
             //
             // For more details see:

Tests/NIOPosixTests/ChannelTests.swift

@@ -2991,7 +2991,7 @@ final class ReentrantWritabilityChangingHandler: ChannelInboundHandler {
 
     func channelActive(context: ChannelHandlerContext) {
         // We want to enqueue at least two pending writes before flushing. Neither of which
-        // should cause writability to change. However, we'll hang a callback off the first
+        // should cause writability to change. However, we'll chain a callback off the first
         // write which will make the channel unwritable and a writability change to be
         // emitted. The flush for that write should result in the writability flipping back
         // again.