-
Notifications
You must be signed in to change notification settings - Fork 175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new phan rule PhanMismatchReturn #4914
Conversation
@@ -372,7 +372,7 @@ function display() | |||
$this->tpl_data['complete'] = true; | |||
|
|||
$this->updateStatus('Complete'); | |||
$Responses = $DB->update( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unused. same with below.
@@ -152,8 +152,6 @@ class Candidate_List extends \NDB_Menu_Filter | |||
'participantstatus' => $participant_status_options, | |||
'useedc' => $config->getSetting("useEDC"), | |||
]; | |||
|
|||
return true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you see this line deleted in this PR in other files, it typically means that the function should actually return void.
@@ -208,7 +208,9 @@ class Create_Timepoint extends \NDB_Form | |||
WHERE CenterID =:cid", | |||
array('cid' => $siteID) | |||
); | |||
$psc_labelOptions[$siteID] = $center['Name']; | |||
if (!is_null($center)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another theme in this PR is verifying that DB results are not null
. Since the pselect*
family does not have any return types it is possible for them to return null
instead of the expected array
of data. This causes phan to get upset when we try to access an array key without first ensuring that the DB result is not null.
@@ -43,7 +43,7 @@ | |||
} else { | |||
$target_path = $base_path . $fileName; | |||
if (move_uploaded_file($_FILES["file"]["tmp_name"], $target_path)) { | |||
$success = $DB->insert( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
insert + update always return void
so they should not be assigned to a value.
This should go to major, not the 21.0-release branch at this point. |
Has 21 been merged back into major? I'll mark this as Needs Rebase for now but I think changing the base branch right now will make all the changes meaningless. |
These are the remaining Pinging @driusan because I think I'll need your help here |
@@ -47,79 +47,79 @@ abstract class AbstractServerProcess | |||
/** | |||
* ID of the process when recorded in the database. | |||
* | |||
* @var int. | |||
* @var int |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Newer versions of phan don't like the .
after the type
The only remaining phan issue (i.e. what is causing Travis to fail) is caused by a reference to DbUnit which is removed by #4433. Until it's merged, this PR will be marked as Blocked. |
EDIT:
@driusan These are my remaining phan errors. Phan doesn't seem to understand what we're doing were with PHPUnit. I tried using the PHPUnit extensions for phan -- no change. I also tried using Mock::generate(CLASS) but that doesn't work with our tests. Any thoughts? |
Are you sure those line numbers are right? In NDB_Factory for those lines I see: line 112: The "MockUser" and "MockNDB_Config" references near those lines both have the |
Yes, sorry I reverted wrong. My issue is this:
If I add
|
I don't think we'll ever be able to fix that since from what I can tell PHPUnit creates the mock classes using eval. https://github.com/sebastianbergmann/phpunit/blob/master/src/Framework/MockObject/MockClass.php#L42 .. the mock objects are dynamically generated code, they're not very amenable to static analysis. Since PHP type hinting doesn't support sum types while doc comments do, our options are either:
Short of refactoring the code, I think this is one of the rare cases where I'd prefer 1, but I have nothing against 2 either. |
I'd prefer approach 1) too. I'll add the suppression and a note explaining it |
I'm getting similar issues with:
I'm going to also add suppressions for these because they're the same species of issue. |
" where id=$parent_id"; | ||
$value = $DB->pselectRow($query, array()); | ||
$value = $DB->pselectRow($query, array()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should use label instead of direct value in query.
@@ -99,7 +99,7 @@ public function handle(ServerRequestInterface $request) : ResponseInterface | |||
* | |||
* @param ServerRequestInterface $request The incoming PSR7 request | |||
* | |||
* @return array | |||
* @return array|\Psr\Http\Message\ResponseInterface |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't make sense to me. Why would a toArray function return a PSR ResponseInterface?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Phan wants this because of the Exception case that returns a 400 response.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay.. it's still a code smell, but it's fine for this PR since it's just documenting what's already there
Brief summary of changes
This PR adds the new phan rule PhanMismatchReturn which flags code that is declared to return a type but in reality returns a different type. e.g.
Turns out we do this all over the place in LORIS so this PR is pretty big.
A lot of phan errors came up related to #4308 so this PR also fixes a lot of those.
There are also minor optimizations/rewrites of functions that were needlessly complicated. In pretty much every case the replacements should be logically equivalent and hopefully more maintainable.