Merge remote-tracking branch 'upstream/develop' into 4.5

 Conflicts:
	phpstan-baseline.php

Author: kenjis

composer.json

@@ -32,7 +32,7 @@
         "phpunit/phpcov": "^8.2",
         "phpunit/phpunit": "^9.1",
         "predis/predis": "^1.1 || ^2.0",
-        "rector/rector": "0.19.2",
+        "rector/rector": "0.19.5",
         "vimeo/psalm": "^5.0"
     },
     "replace": {

contributing/pull_request.md

@@ -3,7 +3,7 @@
 This document declares a set of coding conventions and rules to be followed when contributing PHP code
 to the CodeIgniter project.
 
-**Note:**
+> [!NOTE]
 > While we would recommend it, there's no requirement that you follow these conventions and rules in your
 own projects. Usage is discretionary within your projects but strictly enforceable within the framework.
 
@@ -200,7 +200,7 @@ conditions MUST always be at the beginning or at the end of the line, not a mix
 - The conditional operator, also known simply as the ternary operator, MUST be preceded and followed by at least one space around both the `?` and `:` characters.
 - When the middle operand of the conditional operator is omitted, the operator MUST follow the same style rules as other binary comparison operators.
 
-**Note:**
+> [!NOTE]
 > All the preceding rules are quoted from PSR-12. You may visit its website to view the code block samples.
 
 ## Custom Conventions

contributing/styleguide.md

@@ -16,8 +16,9 @@ values for when you try these:
 
 ## Branching
 
-- All bug fix PRs should be sent to the __"develop"__ branch, this is where the next bug fix version will be developed.
-- PRs with any enhancement should be sent to next minor version branch, e.g. __"4.3"__
+- All bug fix PRs should be sent to the __"develop"__ branch, this is where the
+  next bug fix version will be developed.
+- PRs with any enhancement should be sent to next minor version branch, e.g. __"4.5"__
 
 The "master" branch will always contain the latest stable
 version and is kept clean so a "hotfix" (e.g: an emergency security
@@ -111,23 +112,25 @@ This local branch should be named appropriately, for instance
 "fix/problem123" or "new/mind-reader". The slashes in these branch names
 is optional, and implies a sort of namespacing if used.
 
-- All bug fix PRs should be sent to the __"develop"__ branch, this is where the next bug fix version will be developed.
-- PRs with any enhancement should be sent to next minor version branch, e.g. __"4.3"__
+- All bug fix PRs should be sent to the __"develop"__ branch, this is where the
+  next bug fix version will be developed.
+- PRs with any enhancement should be sent to next minor version branch, e.g. __"4.5"__
 
-For instance, if you send a PR to __"develop"__ branch, make sure you are in the *develop* branch, and create a
-new bugfix branch, based on *develop*, for a new feature you are
-creating:
+For instance, if you send a PR to __"develop"__ branch, make sure you are in the
+*develop* branch, and create a new bugfix branch, based on *develop*, for a new
+feature you are creating:
 
 ```console
 > git switch develop
 > git switch -c fix/problem123
 ```
 
-If you send a PR with an enhancement, make sure you are in the *next minor version* branch,
-and create a new feature branch, based on, e.g., *4.3*, for a new feature you are creating:
+If you send a PR with an enhancement, make sure you are in the *next minor version*
+branch, and create a new feature branch, based on, e.g., __"4.5"__, for a new
+feature you are creating:
 
 ```console
-> git switch 4.3
+> git switch 4.5
 > git switch -c new/mind-reader
 ```
 
@@ -151,23 +154,24 @@ There are some references for writing good commit messages:
 
 If there are intermediate commits that are not meaningful to the overall PR,
 such as "Fix error on style guide", "Fix phpstan error", "Fix mistake in code",
-and other related commits, you can squash your commits so that we can have a clean commit history.
-But it is not a must.
+and other related commits, you can squash your commits so that we can have a
+clean commit history. But it is not a must.
 
 ### Commit Messages
 
-Commit messages are important. They communicate the intent of a specific change, concisely.
-They make it easier to review code, and to find out why a change was made
-if the code history is examined later.
+Commit messages are important. They communicate the intent of a specific change,
+concisely. They make it easier to review code, and to find out why a change was
+made if the code history is examined later.
 
 The audience for your commit messages will be the codebase maintainers,
 any code reviewers, and debuggers trying to figure out when a bug might
 have been introduced.
 
 Make your commit messages meaningful.
 
-Commit messages are expected to be descriptive of **why** and what you changed specifically.
-Commit messages like "Fixes #1234" would be asked by the reviewer to be revised.
+Commit messages are expected to be descriptive of **why** and what you changed
+specifically. Commit messages like "Fixes #1234" would be asked by the reviewer
+to be revised.
 
 You can have as many commits in a branch as you need to "get it right".
 For instance, to commit your work from a debugging session:
@@ -185,7 +189,8 @@ Just make sure that your commits in a feature branch are all related.
 
 ### GPG-Signing Old Commits
 
-Any developer can forget GPG-signing their commits with the option `-S`, like `git commit -S -m 'Signed GPG'`. In such a case, all you need to do is the following:
+Any developer can forget GPG-signing their commits with the option `-S`, like
+`git commit -S -m 'Signed GPG'`. In such a case, all you need to do is the following:
 
 Latest commit only:
 ```console
@@ -235,7 +240,7 @@ are working in.
 At some point, you will decide that your feature branch is complete, or
 that it could benefit from a review by fellow developers.
 
-> **Note**
+> [!NOTE]
 > Remember to sync your local repo with the shared one before pushing!
 It is a lot easier to resolve conflicts at this stage.
 
@@ -267,16 +272,16 @@ On GitHub, you propose your changes one feature branch at a time, by
 switching to the branch you wish to contribute, and then clicking on
 "New pull request".
 
-Make sure the pull request is for the shared __"develop"__ or next minor version branch, e.g. __"4.3"__, or it
-may be rejected.
+Make sure the pull request is for the shared __"develop"__ or next minor version
+branch, e.g. __"4.5"__, or it may be rejected.
 
 Make sure that the PR title is helpful for the maintainers and other
 developers. Add any comments appropriate, for instance asking for
 review.
 
-> **Note**
-> If you do not provide a title or description for your PR, the odds of it being summarily rejected
-rise astronomically.
+> [!NOTE]
+> If you do not provide a title or description for your PR, the odds of it being
+> summarily rejected rise astronomically.
 
 When your PR is submitted, a continuous integration task will be
 triggered, running all the unit tests as well as any other checking we
@@ -306,9 +311,11 @@ And if your PRs have the breaking changes, label the following label:
 
 ## Updating Your Branch
 
-If you are asked for changes in the review, commit the fix in your branch and push it to GitHub again.
+If you are asked for changes in the review, commit the fix in your branch and
+push it to GitHub again.
 
-If the __"develop"__ or next minor version branch, e.g. __"4.3"__, progresses and conflicts arise that prevent merging, or if you are asked to *rebase*,
+If the __"develop"__ or next minor version branch, e.g. __"4.5"__, progresses
+and conflicts arise that prevent merging, or if you are asked to *rebase*,
 do the following:
 
 Synchronize your repository:
@@ -347,7 +354,7 @@ And finally push your local branch to your GitHub repository:
 
 If you have sent a PR to the wrong branch, you need to create a new PR branch.
 
-When you have the PR branch `feat-abc` and you should have sent the PR to `4.3`,
+When you have the PR branch `feat-abc` and you should have sent the PR to __"4.5"__,
 but you created the PR branch from `develop` and sent a PR.
 
 Copy the IDs of any commits you made that you want to keep:
@@ -356,13 +363,13 @@ Copy the IDs of any commits you made that you want to keep:
 > git log
 ```
 
-Update your `4.3` branch:
+Update your __"4.5"__ branch:
 
 ```console
 > git fetch upstream
-> git switch 4.3
-> git merge upstream/4.3
-> git push origin 4.3
+> git switch 4.5
+> git merge upstream/4.5
+> git push origin 4.5
 ```
 
 (Optional) Create a new branch as a backup, just in case:
@@ -371,10 +378,10 @@ Update your `4.3` branch:
 > git branch feat-abc.bk feat-abc
 ```
 
-Rebase your PR branch from `develop` onto `4.3`:
+Rebase your PR branch from `develop` onto __"4.5"__:
 
 ```console
-> git rebase --onto 4.3 develop feat-abc
+> git rebase --onto 4.5 develop feat-abc
 ```
 
 Force push.
@@ -383,7 +390,7 @@ Force push.
 > git push --force-with-lease origin feat-abc
 ```
 
-On the GitHub PR page, change the base branch to the correct branch `4.3`.
+On the GitHub PR page, change the base branch to the correct branch __"4.5"__.
 
 ## Cleanup
 

contributing/workflow.md

@@ -2826,21 +2826,6 @@
 	'count' => 1,
 	'path' => __DIR__ . '/system/Test/PhpStreamWrapper.php',
 ];
-$ignoreErrors[] = [
-	'message' => '#^Method CodeIgniter\\\\Test\\\\TestLogger\\:\\:cleanup\\(\\) has no return type specified\\.$#',
-	'count' => 1,
-	'path' => __DIR__ . '/system/Test/TestLogger.php',
-];
-$ignoreErrors[] = [
-	'message' => '#^Parameter \\#1 \\$level \\(string\\) of method CodeIgniter\\\\Test\\\\TestLogger\\:\\:log\\(\\) should be contravariant with parameter \\$level \\(mixed\\) of method Psr\\\\Log\\\\LoggerInterface\\:\\:log\\(\\)$#',
-	'count' => 1,
-	'path' => __DIR__ . '/system/Test/TestLogger.php',
-];
-$ignoreErrors[] = [
-	'message' => '#^Property CodeIgniter\\\\Test\\\\TestLogger\\:\\:\\$op_logs has no type specified\\.$#',
-	'count' => 1,
-	'path' => __DIR__ . '/system/Test/TestLogger.php',
-];
 $ignoreErrors[] = [
 	'message' => '#^Property CodeIgniter\\\\Throttle\\\\Throttler\\:\\:\\$testTime \\(int\\) on left side of \\?\\? is not nullable\\.$#',
 	'count' => 1,

phpstan-baseline.php

@@ -317,8 +317,8 @@ protected function _fieldData(string $table): array
 
             $retval[$i]->max_length = $length;
 
-            $retval[$i]->default  = $query[$i]->DATA_DEFAULT;
             $retval[$i]->nullable = $query[$i]->NULLABLE === 'Y';
+            $retval[$i]->default  = $query[$i]->DATA_DEFAULT;
         }
 
         return $retval;

system/Database/OCI8/Connection.php

@@ -320,9 +320,9 @@ protected function _fieldData(string $table): array
 
             $retVal[$i]->name       = $query[$i]->column_name;
             $retVal[$i]->type       = $query[$i]->data_type;
+            $retVal[$i]->max_length = $query[$i]->character_maximum_length > 0 ? $query[$i]->character_maximum_length : $query[$i]->numeric_precision;
             $retVal[$i]->nullable   = $query[$i]->is_nullable === 'YES';
             $retVal[$i]->default    = $query[$i]->column_default;
-            $retVal[$i]->max_length = $query[$i]->character_maximum_length > 0 ? $query[$i]->character_maximum_length : $query[$i]->numeric_precision;
         }
 
         return $retVal;

system/Database/Postgre/Connection.php

@@ -359,15 +359,15 @@ protected function _fieldData(string $table): array
         for ($i = 0, $c = count($query); $i < $c; $i++) {
             $retVal[$i] = new stdClass();
 
-            $retVal[$i]->name    = $query[$i]->COLUMN_NAME;
-            $retVal[$i]->type    = $query[$i]->DATA_TYPE;
-            $retVal[$i]->default = $query[$i]->COLUMN_DEFAULT;
+            $retVal[$i]->name = $query[$i]->COLUMN_NAME;
+            $retVal[$i]->type = $query[$i]->DATA_TYPE;
 
             $retVal[$i]->max_length = $query[$i]->CHARACTER_MAXIMUM_LENGTH > 0
                 ? $query[$i]->CHARACTER_MAXIMUM_LENGTH
                 : $query[$i]->NUMERIC_PRECISION;
 
             $retVal[$i]->nullable = $query[$i]->IS_NULLABLE !== 'NO';
+            $retVal[$i]->default  = $query[$i]->COLUMN_DEFAULT;
         }
 
         return $retVal;

system/Database/SQLSRV/Connection.php

@@ -274,12 +274,12 @@ protected function _fieldData(string $table): array
             $retVal[$i]->name       = $query[$i]->name;
             $retVal[$i]->type       = $query[$i]->type;
             $retVal[$i]->max_length = null;
+            $retVal[$i]->nullable   = isset($query[$i]->notnull) && ! (bool) $query[$i]->notnull;
             $retVal[$i]->default    = $query[$i]->dflt_value;
             // "pk" (either zero for columns that are not part of the primary key,
             // or the 1-based index of the column within the primary key).
             // https://www.sqlite.org/pragma.html#pragma_table_info
             $retVal[$i]->primary_key = ($query[$i]->pk === 0) ? 0 : 1;
-            $retVal[$i]->nullable    = isset($query[$i]->notnull) && ! (bool) $query[$i]->notnull;
         }
 
         return $retVal;

system/Database/SQLite3/Connection.php

@@ -21,13 +21,16 @@
  */
 class TestLogger extends Logger
 {
+    /**
+     * @var list<array{level: mixed, message: string, file: string|null}>
+     */
     protected static $op_logs = [];
 
     /**
      * The log method is overridden so that we can store log history during
      * the tests to allow us to check ->assertLogged() methods.
      *
-     * @param string $level
+     * @param mixed  $level
      * @param string $message
      */
     public function log($level, string|Stringable $message, array $context = []): void
@@ -95,6 +98,8 @@ public static function didLog(string $level, $message, bool $useExactComparison
      *
      * @param string $file
      *
+     * @return string
+     *
      * @deprecated No longer needed as underlying protected method is also deprecated.
      */
     public function cleanup($file)