This is an archive of the discontinued LLVM Phabricator instance.

[Inliner][NFC] Remove redundant nullptr check
ClosedPublic

Authored by AlexM on Mar 6 2023, 8:06 PM.

Details

Summary

Remove the null pointer check on Callee since it is guaranteed to pass by the check
at the top of the loop which continues if Callee is null. While this change is somewhat
trivial, for what it's worth this check triggers Coverity warnings because it implies that
Callee might be null at this point even though it is dereferenced in the preceding code.

Diff Detail

Event Timeline

AlexM created this revision.Mar 6 2023, 8:06 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 6 2023, 8:06 PM
AlexM edited the summary of this revision. (Show Details)Mar 7 2023, 9:14 AM
AlexM edited the summary of this revision. (Show Details)Mar 7 2023, 9:27 AM
AlexM added reviewers: mtrofin, kazu.
AlexM published this revision for review.Mar 7 2023, 9:30 AM

I'm very new to this and trying to get my toes wet in the review process with some very minor non-controversial changes. Please let me know if I've made any mistakes in the process.

Herald added a project: Restricted Project. · View Herald TranscriptMar 7 2023, 9:30 AM

I'm very new to this and trying to get my toes wet in the review process with some very minor non-controversial changes. Please let me know if I've made any mistakes in the process.

Would adding an assert(Callee && "Expected to be non-null due to check at the start of the loop") (or something like that) above the if-check make Coverity happy?

AlexM added a comment.Mar 7 2023, 10:38 AM

Would adding an assert(Callee && "Expected to be non-null due to check at the start of the loop") (or something like that) above the if-check make Coverity happy?

Either removing the check completely or moving it from the if to an assert will make Coverity happy. Would the assert be preferable to complete removal from a stylistic/readability perspective?

Would adding an assert(Callee && "Expected to be non-null due to check at the start of the loop") (or something like that) above the if-check make Coverity happy?

Either removing the check completely or moving it from the if to an assert will make Coverity happy. Would the assert be preferable to complete removal from a stylistic/readability perspective?

my preference would be to have an assert, the nullcheck is quite far above, and who knows what future changes will look like; an assert close to the use communicates to the future developer that "this here is intentionally assumed so, because (the comment)".

AlexM updated this revision to Diff 503110.Mar 7 2023, 11:25 AM

Added Callee assert

mtrofin accepted this revision.Mar 7 2023, 12:09 PM
This revision is now accepted and ready to land.Mar 7 2023, 12:09 PM
AlexM added a comment.Mar 7 2023, 1:50 PM

@mtrofin I think I do not have commit access and therefore need you to commit this change on my behalf, is that right?

This revision was automatically updated to reflect the committed changes.