Skip to content

Comments

Fix: remove warnings coming from ss3 source code. Details below#326

Merged
Rick-Methot-NOAA merged 2 commits intomainfrom
test_fallthrough
May 27, 2022
Merged

Fix: remove warnings coming from ss3 source code. Details below#326
Rick-Methot-NOAA merged 2 commits intomainfrom
test_fallthrough

Conversation

@k-doering-NOAA
Copy link
Contributor

What issue(s) does this PR address? Describe and add issue numbers, if applicable.

Issue was not created, but while working on #123, it became clear to me that some of the warning messages coming from SS3 could be taken care of. This will make it easier to identify new/different warnings in the future using github actions, and also cleans up the codebase a bit. In particular, the changes made are:

  • add fallthrough statement to note implicit fallthrough is intentional
  • get rid of maybe uninit warning
  • use multiline comment instead of single line comment to get rid of warning
  • remove parm_adjust_method from create_timevary because unused
  • refactor: clean up comments for time varying so only in 1 place (no warning but found while getting rid of parm_adjust_method)
  • try to fix warning re using wrong type in for statements
  • use int instead of unsigned
  • remove unused variable bio_t_base_from function

Link issue(s) here: n/a

What tests have been done? Upload any model input files created for testing in a zip file, if possible.

periodically, pushed changes to github and checked that the change got rid of the warning using github actions run (note: squashed commits to simplify the PR).

What tests/review still need to be done? Who can do it, and by when is it needed (ideally)?

@Rick-Methot-NOAA should check that none of the changes to fix the warnings are problematic.

Also, Check with the github action that the only remaining warnings are marked as [-Wdeprecated-copy] remain.

I think some work that needs to be done before merging this in is revising the github action (probably in a branch in the workflow repository), so that it can do this same check automatically. The number of warnings expected will also be less than previously expected. I can work on this once Rick verifies the changes are not problematic.

Check which is true. This PR requires:

  • no further changes to r4ss
  • no further changes to the manual
  • no further changes to SSI (the SS3 GUI)
  • no further changes to the stock synthesis change log (new features, bug reports)

Describe any changes in r4ss/SS3 manual/SSI/change log that are needed (if not checked):

Additional information (optional):

@k-doering-NOAA k-doering-NOAA added this to the 3.30.20 milestone May 27, 2022
@k-doering-NOAA k-doering-NOAA force-pushed the test_fallthrough branch 3 times, most recently from ec2f521 to 6038ab4 Compare May 27, 2022 16:02
- add fallthrough statement to note implicit fallthrough is intentional
- get rid of maybe uninit warning
- use multiline comment instead of single line comment to get rid of warning
- remove parm_adjust_method from create_timevary because unused
- refactor: clean up comments for time varying so only in 1 place (no warning but found while getting rid of parm_adjust_method)
- try to fix warning re using wrong type in for statements
- use int instead of unsigned
- remove unused variable bio_t_base_from function
Copy link
Collaborator

@Rick-Methot-NOAA Rick-Methot-NOAA left a comment

Choose a reason for hiding this comment

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

Changes looks good.
Stylistically, should block comments have the /* and */ on separate lines, or OK to have on same line as part of the comment? I see both approaches being used.
I see some of the block comments getting deleted, which seems OK. Those blocks probably were copies of other blocks in order to put the variable descriptions in close proximity to code under development. So, OK to now delete all but one such instance.

@k-doering-NOAA
Copy link
Contributor Author

Thanks @Rick-Methot-NOAA ! Glad you don't see anything that seems harmful. I will work on revising the github action warning run so it takes into account the fewer warnings.

Stylistically, should block comments have the /* and */ on separate lines, or OK to have on same line as part of the comment? I see both approaches being used.

That's a good question to probably address when we decide on a style guide (#311). I don't have a strong preference either way, as someone who does not use block comments very often!

I see some of the block comments getting deleted, which seems OK. Those blocks probably were copies of other blocks in order to put the variable descriptions in close proximity to code under development. So, OK to now delete all but one such instance.

Yep, that was intentional on my part. I thought it made the most sense to define the variables once by the function (as you would do with doxygen, for example), rather than have it copy/pasted many times on the function calls, as you pointed out.

This is because there are still branches that should use the higher count. Until these are merged into main, use this lower count in a branch.
@k-doering-NOAA
Copy link
Contributor Author

@Rick-Methot-NOAA I configured the warnings github action. I think in pushing up a new commit I 'dismissed' your last review. Would you mind hitting "approve" one more time and merging in, if you are ready?

Notes on the github action, mostly for my future self: Right now, it uses it in a branch from the workflows repository, so that branches will still be expecting the correct number of warnings. After we have merged in the current branches, I will move the change to the main branch of workflows and change the ss3 gha to reference it.

Copy link
Collaborator

@Rick-Methot-NOAA Rick-Methot-NOAA left a comment

Choose a reason for hiding this comment

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

I approve these changes.

@Rick-Methot-NOAA Rick-Methot-NOAA merged commit 9740361 into main May 27, 2022
@k-doering-NOAA k-doering-NOAA deleted the test_fallthrough branch May 27, 2022 18:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants