Bug 756395

Summary: [Boost-1.48.0] Qt and [Parse error at "BOOST_JOIN"] error
Product: [Fedora] Fedora Reporter: Denis Arnaud <denis.arnaud_fedora>
Component: qtAssignee: Ngo Than <than>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: bkoz, denis.arnaud_fedora, itamar, jkaluza, jreznik, kevin, laurent.rineau__fedora, ltinkl, pertusus, pmachata, rdieter, rnovacek, smparrish, than
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Fixed In Version: qt-4.8.0-0.27.rc1.fc17 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-03 20:58:37 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 754865    
Description Flags
Workaround none

Description Denis Arnaud 2011-11-23 07:50:45 EST
Description of problem:
Duplication of an external bug, opened against Qt at Nokia: https://bugreports.qt.nokia.com/browse/QTBUG-22829

Version-Release number of selected component (if applicable):
* Boost-1.48.0-1
* Qt-4.{6,7}

The problem does not show up with Boost-1.47.

How reproducible:

Steps to Reproduce:
1. Compile Qt-4.{6,7} with Boost-1.48 on Rawhide
Actual results:
There are multiple compilation errors, such as "Parse error at "BOOST_JOIN", pointing to boost/type_traits/detail/has_binary_operator.hp

Expected results:

Additional info:
It seems the bug is more on the Qt MOC compiler side, as discussed in the Boost mailing lists:
Following are the links to the discussion:
* http://groups.google.com/group/boost-list/browse_thread/thread/212fa3fa2f712206
* http://groups.google.com/group/boost-list/browse_thread/thread/1642b52217e30ff7/313695d3024a0234?show_docid=313695d3024a0234

However, a Boost-related workaround could maybe found (as the issue appeared only from Boost-1.48).
Comment 1 Jan Kaluža 2011-11-24 05:14:08 EST
If you want to test some fixes or workarounds, you can scratch-build my "swift" package which currently doesn't build in rawhide because of this Qt bug.

Here's the build.log: http://koji.fedoraproject.org/koji/getfile?taskID=3531816&name=build.log
Comment 2 Petr Machata 2011-11-30 06:37:00 EST
Created attachment 538531 [details]

Looking into this.  The problematic part is this line in header boost/type_traits/detail/has_binary_operator.hpp:
> namespace BOOST_JOIN(BOOST_TT_TRAIT_NAME,_impl) {

The trouble is, this header is included several times with differing values of BOOST_TT_TRAIT_NAME, so we can't pre-expand it simply.  But I don't suppose the datum is important in any way to the MOC parser, so in the patch, I just make the whole block invisible to MOC.
Comment 3 Petr Machata 2011-11-30 06:39:36 EST
But this is in fact a bug in MOC.  The code is correct on boost side.  I'm reassigning this to Qt in hope you guys can patch around this problem yourself.  But if it's somehow a problem, let me know, and I'll turn in the workaround that I attached above.
Comment 4 Petr Machata 2011-11-30 06:41:46 EST
Here, have this nice reproducer:

#define X(A) A
#define Y a
namespace X(Y) {
  class meh {};

$ g++ -c ble.cc
$ moc-qt4 ble.cc
ble.cc:3: Parse error at "X"
Comment 5 Rex Dieter 2011-11-30 07:53:14 EST
Per the upstream bug, an alternative workaround includes:

"Passing the following to moc will prevent it from parsing through the portion of boost that it is having problems with:
Comment 6 Petr Machata 2011-11-30 09:03:33 EST
Thanks, that's a nice idea.  Jan, does that seem like an acceptable workaround to you?  That would hide from MOC the whole boost/type_traits/has_operator.hpp that drags in the problematic headers.  That would be preferred from my point of view--if we are introducing a kludge, let's do it in the least exposed place.
Comment 7 Kevin Kofler 2011-11-30 10:38:20 EST
A quick hack might be to predefine that macro in MOC, at the same place where QT_MOC_RUN is being predefined at.

The problem is that MOC's C++ parser is quite dumb, it only parses a subset of C++, ignores everything else, and occasionally chokes on something. AFAIK, it doesn't actually do preprocessor expansion at all (and in fact that's sometimes a way to sneak unsupported constructs past MOC, e.g.
"#define foo foo __attribute__((unused))").
Comment 8 Kevin Kofler 2011-11-30 10:40:15 EST
(To clarify my example: MOC will normally just ignore function prototypes and variable declarations entirely, and thus not choke on that attribute, but if you want to put an __attribute__((unused)) on a parameter is a Qt slot, it at least used to not like it.)
Comment 9 Jan Kaluža 2011-12-01 06:19:39 EST
I've tested building swift with "moc-qt4 -DBOOST_TT_HAS_OPERATOR_HPP_INCLUDED" and it worked properly. I will use this workaround for now to get rid of those "Broken dependencies" emails.
Comment 10 Kevin Kofler 2011-12-03 17:23:19 EST
IMHO, littering all packages with this workaround is a very bad idea.

I'm looking into patching MOC to predefine that symbol.
Comment 11 Kevin Kofler 2011-12-03 18:34:06 EST
I added this patch:
to qt-4.8.0-0.27.rc1.fc17, which is now building in Rawhide. I can also add the same workaround to qt3.
Comment 12 Kevin Kofler 2011-12-03 20:58:37 EST
This is now fixed in Rawhide with my 1-line workaround, I'll leave it to the upstreams to come up with a cleaner fix.
Comment 13 Kevin Kofler 2011-12-03 21:08:27 EST
As for qt3, its MOC had a different parser, so I'm only going to patch things if we know it's also affected.
Comment 14 Red Hat Bugzilla 2013-10-03 20:22:10 EDT
Removing external tracker bug with the id '22829' as it is not valid for this tracker