Parser question, requires additional parentheses in order to parse a file

[ds58]

I am working on creating presets for GTSAM. I'm running into a parsing issue with this return statement here, however: https://github.com/borglab/gtsam/blob/develop/gtsam/base/Manifold.h#L131

[ERROR] Failed to execute goal org.bytedeco:javacpp:1.5.8-SNAPSHOT:parse (javacpp-parser) on project gtsam: Failed to execute JavaCPP Builder: /home/d/projects/javacpp-presets-gtsam/gtsam/cppbuild/linux-x86_64/include/gtsam/base/Manifold.h:134:Could not parse declaration at '.'

If I modify this return statement to include additional parentheses, it will parse correctly. Is there anything I may have overlooked in order to avoid this? Or, should I look at modifying the headers in order to please the parser?

Original

  return v0.norm() < tol && traits<T>::Equals(b,c,tol);

Modified

  return (v0.norm() < tol) && (traits<T>::Equals(b,c,tol));

[saudet]

That's most likely a bug in the parser, where it's trying to match the first < with a > it doesn't find...

[ds58]

I think the solution for my case would just be to create patch files that address any minor parsing issues like this. During the build process, the patch files will get applied just after downloading the src.

[saudet]

Yes, the easiest way to work around this kind of small issue is with a patch at build time. That's what happens in the cppbuild.sh file of many presets for a variety of small and not-so-small issues.

In this case, we can probably fix this one in particular and I'll eventually get around to it, but it's not always possible to disambiguate C++ syntax without the whole context. For example, if we had return norm < tol instead, unless we use a full C++ compiler like Clang, see issue bytedeco/javacpp#51, it's not possible to know whether "norm" is a type or a value. If we assume it's a type, we get a syntax error, if we assume it's a value, we get a syntax error for return norm < tol >, so in the case where we don't have access to that information, we need to hack it to allow both syntaxes, but it gets really complicated, and we might as well just use a full C++ compiler, for other reasons too.