GCC 8 Warning Fixes, 21.2 branch (2019.07.16.)
Now that we managed to build a first successful AnalysisBase nightly for the x86_64-centos7-gcc8-opt platform (http://atlas-computing.web.cern.ch/atlas-computing/links/distDirectory/gitwww/GITWebArea/nightlies/21.2/2019-07-16T0755/AnalysisBase/x86_64-centos7-gcc8-opt/AnalysisBase/), it's time to start removing all the compilation warnings that it has.
Most of the updates in this MR are pretty harmless. I had to change the argument of many catch(...) calls to receive the exception objects by constant reference instead of by value. That's not a serious issue.
Many of the warnings in the nightly came from the asg::AnaToolHandle code. Both from some switch(...) statements not having a default clause, and also from one of the catch...: statements not ending in break;. A comment in the code made it clear that this was intentional from @krumnack. But GCC did not understand that comment.
https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/
At first I tried to use the [[gnu::fallthrough]] and [[fallthrough]] expressions to silence that warning, but those for some reason didn't work. But adding this sort of a comment to the code did.
Finally, for the real issues:
- In the
TrigConfHLTDatapackage I had to make the same update that @ssnyder made in the master branch a while ago. And just to say... that code is weird... By now I don't think anymore that it's buggy, but I did think that for quite a while. The bitwise operations done in all the functions around the two that were actually buggy, and which were fixed in this MR, are ridiculous.😦 - The update I made in the b-tagging code should really be looked at by some expert from that area. @tpelzer, could you have a look? And/or pull in anyone else that should? I tried to fix the code as best I understood it, but I could've easily be wrong with what the intention in that piece of code was.
Finally, I didn't touch the QuickAna and SUSYTools packages. Though that may have been a mistake, as some of the warnings showing up there after these updates may still have to do with code outside of those packages...