-
Notifications
You must be signed in to change notification settings - Fork 845
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
Fail CI builds on compiler warnings + some fixes #6675
Conversation
@@ -542,7 +542,7 @@ TEST_CASE("single fragment") { | |||
res = rascalMCES(*m1, *m2, opts); | |||
REQUIRE(res.front().getNumFrags() == 1); | |||
REQUIRE(res.front().getBondMatches().size() == std::get<3>(test)); | |||
REQUIRE(res.front().getLargestFragSize() == | |||
REQUIRE(static_cast<unsigned>(res.front().getLargestFragSize()) == |
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.
getLargestFragSize() should only return a positive integer or 0 - it's the number of atoms in a molecule fragment. However, to support lazy evaluation, the member variable in RascalResult is an int initialised to -1. What's the best way of handling that? getLargestFragSize() could return an unsigned int and then this cast will be unnecessary.
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 we can make getLargestFragSize()
return unsigned int
. It makes sense, since it returns a size. I can take care of that.
@@ -117,7 +117,7 @@ void sorted_degree_seqs( | |||
} | |||
|
|||
// Make labels for the atoms - by default the atomic symbol. | |||
void get_atom_labels(const ROMol &mol, const RascalOptions &opts, | |||
void get_atom_labels(const ROMol &mol, const RascalOptions & /* opts */, |
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.
opts was passed in here in a particularly poor attempt to support chirality matching in the MCES. When it was pointed out just how wrong it was, I took all the code out. I would like to come back to it again at some point, but in the meantime there is no good reason for it. If you think it would be cleaner, I could take it out for now. It's not, and never will be, in the public API and realistically I may never get round to handle chirality.
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 it's fine.
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.
Somehow it missed @greglandrum's "get rid of the underscores" purge, and calc_cost immediately below. If you could fix that in this PR that would be cool, otherwise I'll pop one in after this is accepted.
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 fix the underscores, should I also rip out the opt
arg, or are thinking we might add the chirality option somewhere in the future? I remove the arg before going for this fix, and it results in chain removal from some other functions too, but it's fine, I just need to bring back those changes.
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.
Leave the arg in, I think. It’s a long trek back to the start, and you should probably be spared having to fight through my code like that.
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.
Oh, it's no problem... like I said, I already did it once, and, exactly because it's a long trek, I though it might be better to leave it in place in case we wanted to implement options later on :)
@@ -40,8 +40,8 @@ struct RDKIT_RASCALMCES_EXPORT RascalOptions { | |||
bool returnEmptyMCES = false; /* if true, if the similarity thresholds aren't | |||
matched still return a RascalResult with the | |||
tier1 and tier2 sims filled in. */ | |||
int maxBondMatchPairs = 1000; /* Too many matching bond (vertex) pairs can | |||
cause it to run out of memory. This is a | |||
unsigned maxBondMatchPairs = 1000; /* Too many matching bond (vertex) pairs |
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.
Could we make this explicitly 'unsigned int'? Paolo just spent what I'm sure was a very entertaining time changing all the 'unsigned' to 'unsigned int' in rdFMCS, and it would seem a shame to start the rot again so soon.
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.
Will do.
361aeb6
to
820bf55
Compare
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.
two minor suggestions (well, the same thing twice) to simplify a bit
@@ -148,7 +152,8 @@ bool has_query_feature(const ROMol &mol) { | |||
void add_mol_to_elem(bpt::ptree &elem, const ROMol &mol) { | |||
std::string pkl; | |||
MolPickler::pickleMol(mol, pkl); | |||
std::unique_ptr<char> b64(Base64Encode(pkl.c_str(), pkl.length())); | |||
std::unique_ptr<char, charArrayDeleter> b64( |
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 this is simpler as:
std::unique_ptr<char, charArrayDeleter> b64( | |
std::unique_ptr<char[]> b64( |
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.
Ah, interesting, I had never used that.
@@ -228,7 +233,8 @@ RWMol *pt_to_mol(bpt::ptree &pt) { | |||
auto b64pkl = pt.get<std::string>("pkl", ""); | |||
if (!b64pkl.empty()) { | |||
unsigned int len; | |||
std::unique_ptr<char> cpkl(Base64Decode(b64pkl.c_str(), &len)); | |||
std::unique_ptr<char, charArrayDeleter> cpkl( |
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.
std::unique_ptr<char, charArrayDeleter> cpkl( | |
std::unique_ptr<char[]> cpkl( |
688d17a
to
ff28abf
Compare
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.
One really minor consistency suggestion
unsigned int dummyIdx = mol.addAtom(dummyAt); | ||
bool updateLabel = true; | ||
bool takeOwnwership = true; | ||
unsigned int dummyIdx = mol.addAtom(dummyAt, updateLabel, takeOwnwership); |
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.
wow, I'm surprised this leak hasn't been noticed before.
Bad code review on my part when this was merged
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.
Yeah, I was surprised too
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.
Bad code on my part in the first place :-(. It's quite new code, only in the current release I think, so not so much chance for it to show up.
Much as I like developing on a Mac, I really do miss valgrind.
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.
Have you tried asan?
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 haven’t. I will take a look, thanks.
@@ -102,7 +102,7 @@ TEST_CASE("Small Butina test", "[basics]") { | |||
} | |||
RDKit::RascalMCES::RascalClusterOptions clusOpts; | |||
auto clusters = RDKit::RascalMCES::rascalButinaCluster(mols, clusOpts); | |||
int numMols = 0; | |||
unsigned numMols = 0; |
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.
unsigned numMols = 0; | |
unsigned int numMols = 0; |
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.
Done.
auto newMarvinPlus = new MarvinPlus(); | ||
rxn.pluses.push_back( | ||
std::move(std::unique_ptr<MarvinPlus>(newMarvinPlus))); | ||
auto &newMarvinPlus = rxn.pluses.emplace_back(new MarvinPlus); |
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 like this pattern and was somehow not aware of the fact that emplace_back returns something useful.
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.
Yeah, it's nice. It was added in C++17
@ricrogz : you ready to have this merged? |
Yeah, as long as it builds correctly |
Finally! |
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.
LGTM
This causes the Linux and Mac builds to fail if any compiler warnings are raised during the build. We do this by setting the env var
CXXFLAGS="-Wall -Werror"
. This spares C code, as we don't want to fail due to warnings in thirdparty code like Inchi, Avalon or Yaehmop, and there's too many of them...Note that different compilers/versions raise different warnings, but any supported gcc or clang version should be able to catch the major issues (plus a bunch of annoying stuff like comparing signed vs unsigned). I'm not enabling
-Werror
on windows because the MSVC compiler is way too zealous...Besides enabling the flags, this fixes the warnings that are currently showing up in the builds, so that they don't start failing right after we merge this. And then some mem errors too.