-
Notifications
You must be signed in to change notification settings - Fork 160
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
X3: BOOST_SPIRIT_INSTANTIATE regression #453
Comments
I do not see where you added more workarounds. The problem seems that you have to remove The users that upgrade to a new version can just remove it. Try to add this: boost::spirit::x3::detail::rule_attr_deducer<unused_type const>
: rule_attr_deducer<unused_type> {}; If it will work for you I will add it not to bother people with changing their code. |
I tried the |
Well, that's exactly what I meant to ban: if a parser with has_attribute==true assigns to a rule - that's look suspicious and there should be missing |
Hmm, something strange happens here, I will need more time to dig into this. |
On 2/6/19 6:47 PM, Nikita Kniazev wrote:
Hmm, something strange happens here, I will need more time to dig into this. `BOOST_SPIRIT_INSTANTIATE(grammar_type, iterator_type, context_type)` somehow leads to instantiation of `parse_rule` with `std::string` attribute, I do not understand how it happens.
I think because grammar_type::attribute_type **is** std::string and,
according to what I see on my checkout of that commit, that's
exactly what BOOST_SPIRIT_INSTANTIATE does:
#define BOOST_SPIRIT_INSTANTIATE(rule_type, Iterator, Context)
template bool parse_rule
< Iterator, Context,
rule_type::attribute_type //std::string
(...
So where's the mystery?
|
I edited my message because I missed "for |
I think this happens because of ADL/overload resolution. I was thinking previously why |
Yes, the workaround still works but now I have to place Removing all |
During overload resolution disallowed signature can be instantiated leading to firing the static assertation and overload resolution failure. I could just remove it, but do not want to leave unbounded by value overloads; replacing to not deducing Attribute with specifying a default parameter will not work because we want to allow `BOOST_SPIRIT_DECLARE` without prior `BOOST_SPIRIT_DEFINE` - this requires having default parameters in both declaration and definition and the standard seems to forbid it (GCC - fine, MSVC - warning, Clang - error). Reverts boostorg#437, fixes boostorg#453.
During overload resolution disallowed signature can be instantiated leading to firing the static assertation and overload resolution failure. I could just remove it, but do not want to leave unbounded by value overloads; replacing to not deducing Attribute with specifying a default parameter will not work because we want to allow `BOOST_SPIRIT_DECLARE` without prior `BOOST_SPIRIT_DEFINE` - this requires having default parameters in both declaration and definition and the standard seems to forbid it (GCC - fine, MSVC - warning, Clang - error). Reverts boostorg#437, fixes boostorg#453.
During overload resolution disallowed signature can be instantiated leading to firing the static assertation and overload resolution failure. I could just remove it, but do not want to leave unbounded by value overloads; replacing to not deducing Attribute with specifying a default parameter will not work because we want to allow `BOOST_SPIRIT_DECLARE` without prior `BOOST_SPIRIT_DEFINE` - this requires having default parameters in both declaration and definition and the standard seems to forbid it (GCC - fine, MSVC - warning, Clang - error). Reverts boostorg#437, fixes boostorg#453.
During overload resolution disallowed signature can be instantiated leading to firing the static assertation and overload resolution failure. I could just remove it, but do not want to leave unbounded by value overloads; replacing to not deducing Attribute with specifying a default parameter will not work because we want to allow `BOOST_SPIRIT_DECLARE` without prior `BOOST_SPIRIT_DEFINE` - this requires having default parameters in both declaration and definition and the standard seems to forbid it (GCC - fine, MSVC - warning, Clang - error). Reverts boostorg#437, fixes boostorg#453.
During overload resolution disallowed signature can be instantiated leading to firing the static assertation and overload resolution failure. I could just remove it, but do not want to leave unbounded by value overloads; replacing to not deducing Attribute with specifying a default parameter will not work because we want to allow `BOOST_SPIRIT_DECLARE` without prior `BOOST_SPIRIT_DEFINE` - this requires having default parameters in both declaration and definition and the standard seems to forbid it (GCC - fine, MSVC - warning, Clang - error). Reverts #437, fixes #453.
Thanks a ton for catching this! |
Looks like I will be the bug hunter here. And all of this started accidentally when making a hobby parser project to automate some config generation tasks. The project isn't even at 30% completion and yet, every few commits I encounter weird compilation error or a runtime bug. Most of X3 bugs are catched by the compiler. I think you can expect more issues from me in the future, I haven't even started writing unit tests for my program. Thanks for the fast fix of this, I will test whether I can drop all of current X3 workarounds in my project. |
That's fine. It is cool that you are using develop branch, I am trying not to break it, but the test suite cannot be perfect so I greatly appreciate any additional testing. |
I am using develop branch because the code from official Boost release does not compile. You can view my project as an additional library testing. I don't mind breaking changes. Nonetheless I'm surprised about some bugs ... I would not expect that noone has earlier tried non-copyable types in AST. Apparently there are very few users of X3 yet. |
There were, but no one dig into what happen and it was not on my priority list. I spend more than 10 hours to sort out all the underlying problems and to make a good fix. It is just not a typical use case, with either forward_ast or unique/shared pointers it would not be a problem. I also received a green light from boost::variant maintainer for making recursive_wrapper more like forward_ast (but currently I spend time here =). |
after a3cf3f2 X3 requires existing code to change grammar to add more
const x3::unused_type
workaroundsThis compiles fine just before a3cf3f2:
but after that commit, all grammars that do not syntesize any attribute have to specify
const x3::unused_type
(uncommentconst
)Unfortunately the pull mentioned in https://stackoverflow.com/a/54095167/4818802 does not solve the problem, it only requires code to have more workarounds than previously.
The text was updated successfully, but these errors were encountered: