Single element attributes in X3 "still" broken?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Single element attributes in X3 "still" broken?

sehe
The following parse call fails to compile

    #include <boost/spirit/home/x3.hpp>
    namespace x3 = boost::spirit::x3;
   
    int main() {
        std::string s { "3.14" };
   
        parse(s.begin(), s.end(), x3::rule<struct _> {} = x3::double_);
    }

The old-fashioned workaround - well known throughout the v2.x ages - works:

    #include <boost/spirit/home/x3.hpp>
    namespace x3 = boost::spirit::x3;
   
    int main() {
        std::string s { "3.14" };
   
        parse(s.begin(), s.end(), x3::rule<struct _> {} = x3::double_ >>
x3::eps);
    }


Issue disappears when the `rule<>` is dropped.

Presence or absense of skippers and attributes doesn't affect this.
Specifying the attribute type (x3::rule<struct _, double>) doesn't
affect this.

Issue present on develop & master (25c00abf)

Didn't we see this before? Did someone have a fix for this?

------------------------------------------------------------------------------
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: Single element attributes in X3 "still" broken?

llonesmiz
sehe wrote
The following parse call fails to compile

    #include <boost/spirit/home/x3.hpp>
    namespace x3 = boost::spirit::x3;
   
    int main() {
        std::string s { "3.14" };
   
        parse(s.begin(), s.end(), x3::rule<struct _> {} = x3::double_);
    }

The old-fashioned workaround - well known throughout the v2.x ages - works:

    #include <boost/spirit/home/x3.hpp>
    namespace x3 = boost::spirit::x3;
   
    int main() {
        std::string s { "3.14" };
   
        parse(s.begin(), s.end(), x3::rule<struct _> {} = x3::double_ >>
x3::eps);
    }


Issue disappears when the `rule<>` is dropped.

Presence or absense of skippers and attributes doesn't affect this.
Specifying the attribute type (x3::rule<struct _, double>) doesn't
affect this.

Issue present on develop & master (25c00abf)

Didn't we see this before? Did someone have a fix for this?

------------------------------------------------------------------------------
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
I'm far from an expert, but I don't think it has anything to do with single element attributes (changing double_ with int_ for example works). I think the problem is a missing "const" in real_parser's "parse" signature:

bool parse(Iterator& first, Iterator const& last
          , Context& context, unused_type, T& attr_) const

I think needs to be:

bool parse(Iterator& first, Iterator const& last
          , Context const& context, unused_type, T& attr_) const

"double_ >> eps" works because sequence does have the const in its parse function.
Reply | Threaded
Open this post in threaded view
|

Re: Single element attributes in X3 "still" broken?

sehe
On 11/13/2015 11:24 AM, llonesmiz wrote:

> sehe wrote
>> The following parse call fails to compile
>>
>>     #include &lt;boost/spirit/home/x3.hpp&gt;
>>     namespace x3 = boost::spirit::x3;
>>    
>>     int main() {
>>         std::string s { "3.14" };
>>    
>>         parse(s.begin(), s.end(), x3::rule
>> <struct _>
>>  {} = x3::double_);
>>     }
>>
>> The old-fashioned workaround - well known throughout the v2.x ages -
>> works:
>>
>>     #include &lt;boost/spirit/home/x3.hpp&gt;
>>     namespace x3 = boost::spirit::x3;
>>    
>>     int main() {
>>         std::string s { "3.14" };
>>    
>>         parse(s.begin(), s.end(), x3::rule
>> <struct _>
>>  {} = x3::double_ >>
>> x3::eps);
>>     }
>>
>>
>> Issue disappears when the `rule<>` is dropped.
>>
>> Presence or absense of skippers and attributes doesn't affect this.
>> Specifying the attribute type (x3::rule
>> <struct _, double>
>> ) doesn't
>> affect this.
>>
>> Issue present on develop & master (25c00abf)
>>
>> Didn't we see this before? Did someone have a fix for this?
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Spirit-general mailing list
>> Spirit-general@.sourceforge
>> https://lists.sourceforge.net/lists/listinfo/spirit-general
> I'm far from an expert, but I don't think it has anything to do with single
> element attributes (changing double_ with int_ for example works). I think
> the problem is a missing "const" in real_parser's "parse" signature:
>
> bool parse(Iterator& first, Iterator const& last
>           , Context& context, unused_type, T& attr_) const
>
> I think needs to be:
>
> bool parse(Iterator& first, Iterator const& last
>           , Context const& context, unused_type, T& attr_) const
>
> "double_ >> eps" works because sequence does have the const in its parse
> function.
>

O hey. Sorry for introducint a red herring. I'm glad it's probably not
the attribute compatibiility :)

I'll look at this hint more later.

Let me add for now that I didn't just jump to the conclusion, I have met
with this quirk using other parsers. Of course, it could be the same
missing const in those cases.

Example: http://coliru.stacked-crooked.com/a/c2db66e432ea9b72 (look for
the `eps` es)

If I can confirm your hypothesis, I'll try to turn it into a PR

------------------------------------------------------------------------------
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: Single element attributes in X3 "still" broken?

sehe
On 13-11-15 15:05, Seth wrote:
I'll look at this hint more later.

Let me add for now that I didn't just jump to the conclusion, I have met
with this quirk using other parsers. Of course, it could be the same
missing const in those cases.

Example: http://coliru.stacked-crooked.com/a/c2db66e432ea9b72 (look for
the `eps` es)

I've uncovered yet a case where things break. Uncommenting `>> x3::eoi` breaks compilation here:

#include <boost/fusion/include/adapt_struct.hpp>
#include <boost/spirit/home/x3.hpp>

namespace x3 = boost::spirit::x3;

struct inner { int value;   };
struct outer { inner value; };

BOOST_FUSION_ADAPT_STRUCT(inner, value)
BOOST_FUSION_ADAPT_STRUCT(outer, value)

namespace sample {
    auto const rule = x3::rule<struct return_class, outer> {}
                    = x3::attr(inner{42}) >> ';';
}

#include <iostream>
int main() {
    std::string const input = ";";

    outer s;
    bool ok = parse(input.begin(), input.end(), sample::rule/* >> x3::eoi*/, s);
    assert(ok);
}
The code is seen trying to `move_to` [Source=outer; Dest=int]. That makes no sense. It appears to be due to repeated "unwrapping" of nested single-element sequences.

[The same mechanism happening in the fusion adapted structs as well as in the passed attribute?]

Does anyone see the real issue here?


------------------------------------------------------------------------------

_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: Single element attributes in X3 "still" broken?

Joel de Guzman
On 12/14/15 10:03 AM, Seth wrote:

> I've uncovered yet a case where things break. Uncommenting `>> x3::eoi` breaks compilation
> here:
>
[snipped for brevity, see previous context]
>
> The code is seen trying to `move_to` [Source=outer; Dest=int]. That makes no sense. It
> appears to be due to repeated "unwrapping" of nested single-element sequences.
>
> [The same mechanism happening in the fusion adapted structs as well as in the passed
> attribute?]
>
> Does anyone see the real issue here?

The problem seems to be with parse_sequence partition_attribute. Somehow, it is passing
inner to the rule instead of outer. I think partition_attribute is trying to be smart
and unwraps the single-element sequence in pass_sequence_attribute_used (line 107
operator/detail/sequence.hpp). I think this pertains to rules, in particular, and
parsers that has Parser::is_pass_through_unary == false, in general.

Whether that is unwanted or not is the basic *design* question! There's a reason
for its existence: partition-sequence itself may produce this one-element
sequence by the very act of partitioning. Perhaps one solution is to *ONLY*
do the unwrapping if the single-element sequence comes from partitioning,
or is intended by the user.

I've ran out of time today. I'll get back to it again while it's still fresh.
In the meantime, if anyone has a better understanding and solution, that would
be very welcome! C'mon and get dirty with some X3 hacking!

Cheers,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


------------------------------------------------------------------------------
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: Single element attributes in X3 "still" broken?

Joel de Guzman
On 12/23/15 7:50 AM, Joel de Guzman wrote:

> On 12/14/15 10:03 AM, Seth wrote:
>
>> I've uncovered yet a case where things break. Uncommenting `>> x3::eoi` breaks compilation
>> here:
>>
> [snipped for brevity, see previous context]
>>
>> The code is seen trying to `move_to` [Source=outer; Dest=int]. That makes no sense. It
>> appears to be due to repeated "unwrapping" of nested single-element sequences.
>>
>> [The same mechanism happening in the fusion adapted structs as well as in the passed
>> attribute?]
>>
>> Does anyone see the real issue here?
>
> The problem seems to be with parse_sequence partition_attribute. Somehow, it is passing
> inner to the rule instead of outer. I think partition_attribute is trying to be smart
> and unwraps the single-element sequence in pass_sequence_attribute_used (line 107
> operator/detail/sequence.hpp). I think this pertains to rules, in particular, and
> parsers that has Parser::is_pass_through_unary == false, in general.
>
> Whether that is unwanted or not is the basic *design* question! There's a reason
> for its existence: partition-sequence itself may produce this one-element
> sequence by the very act of partitioning. Perhaps one solution is to *ONLY*
> do the unwrapping if the single-element sequence comes from partitioning,
> or is intended by the user.
>
> I've ran out of time today. I'll get back to it again while it's still fresh.
> In the meantime, if anyone has a better understanding and solution, that would
> be very welcome! C'mon and get dirty with some X3 hacking!

OK, the solution I mentioned above seems to be working fine! I'll go run the
full regression tests to make sure nothing is broken and push the fix to develop.

Cheers,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


------------------------------------------------------------------------------
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: Single element attributes in X3 "still" broken?

Joel de Guzman
On 12/24/15 6:52 AM, Joel de Guzman wrote:
> On 12/23/15 7:50 AM, Joel de Guzman wrote:
>> On 12/14/15 10:03 AM, Seth wrote:

>> The problem seems to be with parse_sequence partition_attribute. Somehow, it is passing
>> inner to the rule instead of outer. I think partition_attribute is trying to be smart
>> and unwraps the single-element sequence in pass_sequence_attribute_used (line 107
>> operator/detail/sequence.hpp). I think this pertains to rules, in particular, and
>> parsers that has Parser::is_pass_through_unary == false, in general.
>>
>> Whether that is unwanted or not is the basic *design* question! There's a reason
>> for its existence: partition-sequence itself may produce this one-element
>> sequence by the very act of partitioning. Perhaps one solution is to *ONLY*
>> do the unwrapping if the single-element sequence comes from partitioning,
>> or is intended by the user.
>>
>> I've ran out of time today. I'll get back to it again while it's still fresh.
>> In the meantime, if anyone has a better understanding and solution, that would
>> be very welcome! C'mon and get dirty with some X3 hacking!
>
> OK, the solution I mentioned above seems to be working fine! I'll go run the
> full regression tests to make sure nothing is broken and push the fix to develop.

This 'fix' is now in develop.

Regards,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: Single element attributes in X3 "still" broken?

sehe
On Mon, Feb 8, 2016, at 12:54 AM, Joel de Guzman wrote:

> This 'fix' is now in develop.
>
> Regards,
> --
> Joel de Guzman

That's great. I have good hopes that this will now be a relic of the
past!

Seth

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general