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

[WIP] Clang tidy fixes #26

Draft
wants to merge 38 commits into
base: master
Choose a base branch
from
Draft

Conversation

jtxa
Copy link
Contributor

@jtxa jtxa commented Nov 5, 2022

ATTENTION: this PR is not for a detailed review.

Please have a rough look at each commit (maybe just the first 2-3 changes), which kind of auto-fix makes sense.
I will post my conclusion hopefully within a day (I do not have time now).

When we decide on which fixes shall be applied, I will look into every change in detail.

Short summary up-front:

  • all look useful
  • modernize-loop-convert maybe needs loop variables renamed for clarity
  • modernize-use-trailing-return-type is weird, I would not apply it

@jtxa jtxa mentioned this pull request Nov 5, 2022
9 tasks
@jtxa
Copy link
Contributor Author

jtxa commented Nov 5, 2022

We should definitely not apply fixes that break the build ;-)
But maybe that was caused by manually rebasing it. For this first review the rebase was faster then re-applying with the tool.
For the real change I will run the tool again (I have that automated). And check if it builds.

@jtxa
Copy link
Contributor Author

jtxa commented Nov 6, 2022

My wording:

  • must fix: I guess everyone will agree (with the goal to avoid bugs)
  • fix: useful, most people will agree
  • ok: useful (but I don't have an opinion, I'm usually stuck to C++98 myself)
  • no: I wouldn't do it

Copy link
Owner

@sierrafoxtrot sierrafoxtrot left a comment

Choose a reason for hiding this comment

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

This is a really useful set of checks and improvements Josef. A couple of comments and probably a few to discuss.

srecord/arglex.cc Show resolved Hide resolved
srecord/arglex.cc Show resolved Hide resolved
srecord/output/file/msbin.cc Show resolved Hide resolved
srecord/arglex/test_ambiguous.cc Show resolved Hide resolved
srecord/output/file/msbin.cc Show resolved Hide resolved
srecord/arglex.cc Show resolved Hide resolved
srecord/output/file/aomf.cc Show resolved Hide resolved
srecord/input/file/guess.cc Show resolved Hide resolved
srecord/arglex.cc Show resolved Hide resolved
srecord/input/file/needham.h Show resolved Hide resolved
@sierrafoxtrot
Copy link
Owner

sierrafoxtrot commented Nov 6, 2022

Ok, I didn't realise you were still working on this at the same time as me. I'm trying desperately to avoid doing that, sorry. I'll go back through my list of comments and review your assessment. Please, hold off updating for a few hours to give me a chance to get through it.

@sierrafoxtrot
Copy link
Owner

sierrafoxtrot commented Nov 6, 2022

I hope this summary list below still lines up with the review comments above. If in doubt, the review comments were written later if that helps).

Summary of responses. The review comments might site specifics etc but the main comments are here: - SF

SF: discuss (or default to no): As mentioned in my review comment, clang-tidy didn't seem consistent in when it triggered on this. In principle, the check itself is ok.

SF: yes (and agree with your approach to the fix)

SF: yes

SF: Yes. Your notes make more sense than the changes clang-tidy provided LOL. Definitely keen for this to be a well written and reviewed fix!

  • readability-uppercase-literal-suffix: fix; it's a must for L, but other static code analyzers (and coding standards) I know, they do uppercase for every suffix; so it's probably just u-U changes

SF: YES!

SF: yes: If these are a consequence of other changes making things static that weren't previously, then lets go with it.

SF: yes

SF: yes (my review comments danced around on this one but seems more in keeping with moving defaults to declarations.

SF: yes

SF: yes (as auto is now being used)

SF: yes

SF: yes

SF: yes

SF: yes (but agree the more meaningful name isn't always the one that has been suggested here. In most cases, the header is better which makes sense, peter always wrote interfaces first almost to completeness and then filled in the implementation.

SF: no, (or perhaps discuss). In some instances the implicity bool makes sense isupper() reads nicely to humans. But boolean checks against zero make me queasy. On balance, no but happy to chat more.

SF: discuss: I like the idea of code review/improve. But I do think the current form is easier to read in terms of intent.

SF: yes

SF: yes (a holdover from earlier times)

SF: yes but agree on the review.

SF: yes

SF: yes. (My current day-job is on medical devices. Can confirm!)

SF: no (my default is to leave it unless there is a benefit.)

SF: no (agreed wholeheartedly with your reasoning)

SF: discuss: Keen to understand the value. I may just be out-of-date on this one.

SF: yes

SF: discuss: Not sure of the benefit here. Declaring without implementing (as already done) has exactly the same effect. I guess this is more explicit; is that th epoint?

SF: yes

SF: yes

SF: Yes (see my comment in the review but really like this

SF: YES!

SF: yes

SF: yes

SF: yes (only because it is the easiest way to get consistency :-) )

SF: yes

SF: no - complexity for no obvious benefit (we aren't shifting megabytes around in any of these). Happy to be convinced otherwise.

SF: yes. If we are going to make some of the other modernize fixes, this one may as well go in.

SF: yes.

SF: yes - but I'm nervous about cutting off folks on older platforms which was litterally the original usecase for SRecord. Chances are this worry is completely unfounded.

My wording:

  • must fix: I guess everyone will agree (with the goal to avoid bugs)

  • fix: useful, most people will agree

  • ok: useful (but I don't have an opinion, I'm usually stuck to C++98 myself)

  • no: I wouldn't do it

Adding:

  • yes: Let's do this
  • discuss: No strong opinion but aware I may not have all the answers either. Default is otherwise, no
  • no: Preference is to avoid but please argue your point if you feel strongly

@jtxa jtxa mentioned this pull request Jan 13, 2023
@jtxa
Copy link
Contributor Author

jtxa commented Jan 27, 2023

Update:
most messages were fixed in #32

These were agreed to be not fixed:

modernize-pass-by-value
modernize-use-trailing-return-type
modernize-use-using

So these messages are left, which can be autofixed (but may need manual changes or reviews, see comments above)

bugprone-implicit-widening-of-multiplication-result
cppcoreguidelines-init-variables
cppcoreguidelines-pro-type-member-init
modernize-loop-convert
modernize-use-default-member-init
modernize-use-equals-default
modernize-use-equals-delete
modernize-use-nullptr
modernize-use-override
readability-braces-around-statements
readability-convert-member-functions-to-static
readability-else-after-return
readability-implicit-bool-conversion
readability-inconsistent-declaration-parameter-name
readability-redundant-member-init
readability-redundant-string-init

For the current state of unfixed messages see .clang-tidy which also contains other warnings which may need to be discussed and manually fixed.

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.

None yet

2 participants