Make Clang-Tidy happy

[agarny]

Addresses issue #595.

[agarny]

@hsorby, @nickerso and @kerimoyle : it should literally take less than 2 minutes to review this.

[nickerso]

are any of our CI systems using this new version of Clang tidy?

[agarny]

I would think not unless @hsorby updated our CI Mac?

[agarny]

Actually, trying to connect to the Mac, I am getting told that libCellML is using the display. Why?! (This is not the first time that I see that.)

Anyway, I have logged in, and Homebrew was still locked since the end of January (!?). I removed the locks and tried to upgrade Homebrew, but now I am being told that I don't have write access to some files... because things were previously updated and file access is set to 755...!?

Anyway nb 2, Screen Sharing has gone completely black on me. Giving up. (I tried to reconnect and I am once again being told that libCellML is using the display...!?)

[agarny]

FTR, our CI Mac is currently doing a brew upgrade. So, just a matter of time before Clang-Tidy gets updated to 10.0.0.

[agarny]

Ok, FWIW, the CI Mac now uses Clang-Tidy 10.0.0 and I have just retriggered the tests. So, it's all good for you, @nickerso, @hsorby and @kerimoyle, to review and merge in (so that we can then onto PR #599 and then PR #598 (in that order).

[kerimoyle]

Does this mean that our own machines also need to be upgraded? And what do the new flags surrounding auto mean we need to do differently?

[agarny]

No, if you have an older version of Clang-Tidy (as was the case for our CI Mac) then it will still be fine. If you don't have Clang-Tidy installed on your system, our build system will skip some checks, so fine again.

It's just that my copy of Clang-Tidy is up to date, so I can't build the develop version of libCellML unless I disable Clang-Tidy. So, this PR fixes our build system so that it not only works with "old" versions of Clang-Tidy, but also with the latest one.

[kerimoyle]

Works ok for me.

[nickerso]

Do we need to document why we choose a given configuration option for this? or is it sufficient to say we configure Clang Tidy to match our style guide and assume that people know what they are doing? (Just asking as these options being added mean nothing to me so don't feel I can review it if by doing so would imply that I agree to these options.)

[agarny]

I don't know if it is worth documenting this somewhere. Our code mentions that the full list of Clang-Tidy checks can be found at https://clang.llvm.org/extra/clang-tidy/checks/list.html. When it comes to the ones that I have added, you can see their description at https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-init-variables.html and at https://clang.llvm.org/extra/clang-tidy/checks/readability-qualified-auto.html.

The reason I have added those "two" checks is that for the initial variables check, it would require changing a hell of a lot of the code (something that we might want to do at some point though?) while for the second one I thought it made the use of auto somewhat cumbersome. I mean, that check wants you to use auto * for pointers while the whole point of auto for me is that I don't have to second-guess the type of the variable I am dealing with.

Open to suggestions though...

[nickerso]

These changes seem to be working on the one CI machine that has an updated clang tidy, so happy to approve them. We may want to review our Clang Tidy config at some point in the future...