Boost C++ Libraries: Ticket #4109: xpressive compile error (MingW GCC 4.5)

attachment set

Sat, 17 Apr 2010 17:56:05 GMT

attachment → untitled.JPG

Compilation tells error at line #109 of my code

attachment set

Sat, 17 Apr 2010 17:59:29 GMT

attachment → errors.txt

the error message reported by mingw gcc 4.5

cc set

Sat, 17 Apr 2010 18:00:55 GMT

cc duzy@… added

summary changed

Sat, 17 Apr 2010 18:01:35 GMT

summary xpressive compile error → xpressive compile error (MingW GCC 4.5)

anonymous — Sun, 18 Apr 2010 07:45:28 GMT

I can confirm the problem for g++-4.5 in Debian Sid as well as cross-compilers to sparc-sun-solaris2.8, i386-portbld-freebsd7.2 and x86_64-portbld-freebsd7.2 built from unpatched gcc-4.5.0 sources.

This seems to be related to optional subexpressions; at least I can make it show up with that. The simplest case I can come up with is

#include <boost/xpressive/xpressive.hpp>
int main() {
  using namespace boost::xpressive;
  // This compiles if rex is given as
  // sregex rex = _w;
  sregex rex = !_w;
}

anonymous — Sun, 18 Apr 2010 07:47:08 GMT

I mean g++-4.5 from Debian experimental (4.5.0-1), sorry.

status changed

Eric Niebler — Mon, 19 Apr 2010 23:17:29 GMT

status new → assigned

Yup, looks like xpressive is broken on gcc-4.5. Earlier versions of gcc are fine.

milestone changed

Eric Niebler — Mon, 19 Apr 2010 23:24:39 GMT

milestone Boost 1.43.0 → Boost 1.44.0

changed milestone to 1.44. Too late for 1.43.

keywords changed

Eric Niebler — Tue, 20 Apr 2010 00:51:26 GMT

keywords template_arity added

After a bit of digging, it seems the problem is actually in MPL (and by admission, in xpressive's reliance on an implementation detail of MPL). The following program, which compiles on gcc-4.4 but not on gcc-4.5, demonstrates the problem:

  #include <boost/mpl/aux_/template_arity.hpp>
  #include <boost/mpl/aux_/lambda_arity_param.hpp>
  template<class A>
  struct T : A::x
  {};
  template<
    class T
    BOOST_MPL_AUX_LAMBDA_ARITY_PARAM(
      int Arity = boost::mpl::aux::template_arity<T>::value
    )
  >
  struct S
  {};
  template<template<class A> class P, class X>
  struct S<P<X> BOOST_MPL_AUX_LAMBDA_ARITY_PARAM(1)>
  {};
  int main()
  {
    S<T<int> > s0;
  }

anonymous — Tue, 20 Apr 2010 08:15:47 GMT

Oh boy. There's a deep pool of template magic behind that one.

It could be that I'm missing arcane properties of half-instantiated templates, but it looks to me like the problem is using an invalid type in the first place (T<int>). I'm actually a bit surprised that it doesn't complain about S<T<int>, 1>.

In any case, if the tag only has to be there and isn't actually used, that offers a quick and rather dirty workaround, namely

--- arg.hpp~	2010-03-02 04:19:57.000000000 +0100
+++ arg.hpp	2010-04-20 10:08:28.000000000 +0200
@@ -142,6 +142,9 @@
     template<int N>
     struct _child_c : transform<_child_c<N> >
     {
+        // Just to have one
+        typedef tag::comma proto_tag;
+
         template<typename Expr, typename State, typename Data>
         struct impl : transform_impl<Expr, State, Data>
         {

where boost::proto::tag::comma is chosen arbitrarily from a number of proto tags that allow boost::xpressive::detail::width_of to be instantiated without making any deeper inquiries about Expr.

status changed; resolution set

Eric Niebler — Tue, 20 Apr 2010 23:01:13 GMT

status assigned → closed
resolution → duplicate

This is a duplicate of #4061. I can confirm that the patch attached to that ticket fixes this problem. It's too late for 1.43, but hopefully we can get it in for 1.44.

Wed, 21 Apr 2010 14:41:41 GMT

So great to see post. Thanks, eric.