-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Fix shadow variables #2482
Conversation
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.
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?
@@ -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 |
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.
@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; |
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 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?
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.
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
@@ -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
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.
CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.
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? |
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! |
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.
I'm happy keeping the work going, all good. I would definitely do the fix of the
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 Does this relate to the failure in
Thanks for the kind words, I'll come back with the changes in a few hours/days. |
I fixed a comment. We'll set what CI does, if it fails I can render more advice! |
Is there anything else needed before merging? |
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! |
Change Description
Add support of
-wShadow
in the code base.Forseen changes are:
m_
toprivate
andprotected
class membersa_
to arguments shadowing apublic
class memberThe
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 becomeprotected
instead ofpublic
, 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#381I 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