Skip to content
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

Fix shadow variables #2482

Merged
merged 8 commits into from
Feb 1, 2024
Merged

Conversation

JohanBertrand
Copy link
Contributor

@JohanBertrand JohanBertrand commented Jan 13, 2024

Related Issue(s) None
Has Unit Tests (y/n) N/A
Documentation Included (y/n) N/A

Change Description

Add support of -wShadow in the code base.

Forseen changes are:

  • Add a prefix m_ to private and protected class members
  • Add a prefix a_ to arguments shadowing a public class member
  • Change variable names to avoid shadowing class member
  • Remove redundant variable definition with same name

The a_ prefix has been chosen to avoid breaking changes in the code. Changing the name of public variables can have a bigger impact on other projects. However, I think some of those variables should become protected instead of public, and the _m prefix should be used on those class members in the future. I think it's an open point of discussion.

A full compatibility with -wShadow will require some changes also in fpp. See nasa/fpp#381
I am not sure what would be the release schedule. We might want to keep the -Wshadow flag out until the next fpp release happens.

Rationale

Shadow variables can make the code more difficult to read and debug.

Testing/Review Recommendations

TBD

@JohanBertrand JohanBertrand marked this pull request as draft January 13, 2024 02:10
@JohanBertrand JohanBertrand changed the title draft: Fix shadow variables Fix shadow variables Jan 13, 2024
@JohanBertrand JohanBertrand marked this pull request as ready for review January 18, 2024 16:00
Copy link
Collaborator

@LeStarch LeStarch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there is only one required change I see: comment out the -Wshadow in the
Ref package until the PR on FPP makes its way over.

If you are so-motivated, there are a few other minor comments on other cleanup items....however, none of these are required in this PR. I'll take the action to add tickets as we need something to track this work.

@bocchino or @thomas-bc this is a big PR but entirely formulaic, would one of you take a look to ensure I did not miss anything?

CMakeLists.txt Outdated Show resolved Hide resolved
Fw/FilePacket/DataPacket.cpp Show resolved Hide resolved
Ref/CMakeLists.txt Show resolved Hide resolved
@@ -27,9 +27,9 @@ namespace STest {

//! Construct object Rule
Rule(
const char *const name //!< The name of the rule
const char *const a_name //!< The name of the rule
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bocchino we will need to look into this w.r.t. the STest repository. If and when we move to a full sub-repo, we'll need to ensure shadows are weeded-out.

I'll leave that to you to track before we make STest a subrepo.

}

PRIVATE:

//! The total number of warnings
U32 n;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another minor nit, not blocking for this PR....but given this PR is changing much, could we rename this to m_warning_count or something more descriptive?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the m_n variable names to something more descriptive, and updated the comments of the variables. Let me know if there is a mistake in the comments

@@ -291,7 +291,7 @@
// Constructor
// ----------------------------------------------------------------------

FilePacket() { this->header.type = T_NONE; }
FilePacket() { this->m_header.type = T_NONE; }

Check notice

Code scanning / CodeQL

More than one statement per line Note

This line contains 3 statements; only one is allowed.
@@ -43,32 +43,32 @@
public:

//! Constructor
Mode() : value(IDLE) { }
Mode() : m_value(IDLE) { }

Check notice

Code scanning / CodeQL

More than one statement per line Note

This line contains 2 statements; only one is allowed.
Copy link

@github-advanced-security github-advanced-security bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

@LeStarch LeStarch linked an issue Jan 18, 2024 that may be closed by this pull request
@LeStarch
Copy link
Collaborator

The CI failures are likely due to unit testing. Much of our unit testing relies on white-box testing and as such does access these private members. We'll need to fix those too. @JohanBertrand are you up for this fix?

@LeStarch
Copy link
Collaborator

In case this isn't clear, this is solid work. Thanks for the contribution. Feel free to communicate us if you have reached the limit of what you are able to work on and we can move it through the process, otherwise we'll let you move it forward!

@JohanBertrand
Copy link
Contributor Author

I think there is only one required change I see: comment out the -Wshadow in the Ref package until the PR on FPP makes its way over.

From what I've seen, it works well because the warning flags apply only to the user code, and not to the auto generated code. The unit tests and the build on Ref were working fine for me.

If you are so-motivated, there are a few other minor comments on other cleanup items....however, none of these are required in this PR. I'll take the action to add tickets as we need something to track this work.

I'm happy keeping the work going, all good. I would definitely do the fix of the a_ prefix in another PR to make it easier to review, but I'll go through the rest.

The CI failures are likely due to unit testing. Much of our unit testing relies on white-box testing and as such does access these private members. We'll need to fix those too. @JohanBertrand are you up for this fix?

It was compiling well for me. I already did changes in the test files, but just a few were needed. I did not run the check though. I'll double check, thanks.

Does this relate to the failure in CI / Framework (pull_request)?

In case this isn't clear, this is solid work. Thanks for the contribution. Feel free to communicate us if you have reached the limit of what you are able to work on and we can move it through the process, otherwise we'll let you move it forward!

Thanks for the kind words, I'll come back with the changes in a few hours/days.

@JohanBertrand
Copy link
Contributor Author

@LeStarch it should be good to go, let me know if something else is need

I'll work on #2492 once this PR is closed

@LeStarch
Copy link
Collaborator

I fixed a comment. We'll set what CI does, if it fails I can render more advice!

@JohanBertrand
Copy link
Contributor Author

Is there anything else needed before merging?

@LeStarch
Copy link
Collaborator

LeStarch commented Feb 1, 2024

I have approved, was hoping for one more set of eyes on this because of the extensive length of the PR. Once we get that it will be merged!

@LeStarch LeStarch merged commit f0f19ba into nasa:devel Feb 1, 2024
34 checks passed
@LeStarch LeStarch added the Update Instructions Needed Need to add instructions in the release notes for updates. label Feb 14, 2024
@JohanBertrand JohanBertrand deleted the Fix-shadow-variables branch April 29, 2024 22:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Update Instructions Needed Need to add instructions in the release notes for updates.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Resolve Warnings for -Wshadow
3 participants