Actually the warning here is a sign of bad design. Attribute should go directly
to sink, and there will be no truncation warning except a situation when sink
is not wide enough for attribute or binded value.
Closes https://svn.boost.org/trac10/ticket/11540.
Actually this should have been caught by `regression_matlib_generate_switch`
test, but it is not complex enough to cover all cases. We do not have the
coverage reports yet, but the fix is trivial so I think it is ok.
The concept of ForwardIterator is flawed because it mixed 2 sets of concepts (value access and traversal) into 1 package.
http://www.boost.org/doc/libs/1_65_1/libs/iterator/doc/new-iter-concepts.html
It requires value_type (const)& as return type when dereference is applied, which is not mandatory in spirit parsing. A return type which is convertible to value_type is good enough. ReadableIteratorConcept and ForwardTraversalConcept should be what we need for the iterator check.
For example, the iterator of the range returned by boost::adaptors::transform(std::string, func) is normally not a ForwardIterator. But it fulfills ReadableIteratorConcept and ForwardTraversalConcept and should be able to be parsed by spirit.
Closes https://svn.boost.org/trac10/ticket/12473
Optional parser never fails so `attr = val;` always triggers and initializes
the `attr` value. The special case for optional attributes could be safely
removed as any underlying parser must already correctly handle optionals.
..\libs\spirit\test\qi\rule_fail.cpp(28): error C2872: 'char_': ambiguous symbol
boost/spirit/home/support/common_terminals.hpp(235): note: could be 'const boost::spirit::ascii::char_type boost::spirit::ascii::char_'
boost/spirit/home/support/common_terminals.hpp(237): note: or 'const boost::spirit::standard::char_type boost::spirit::standard::char_'
After two hours of fighting with the optimizer, I happily drew attention to
this little nifty bitwise operator in `any_if_ns` function.
Explanation of the bug: bitwise inclusive OR operator is not a sequence point
(per chapter §5.13 of C++14 standard), that's why at compiling the expression
`a() | b() | ... | z()` optimizer is allowed to rearrange the execution order
of the functions `a`, `b` ... `z`.
There is high chance that a lot of people were misguided by the bug and chose
not to use `sequential_or`.
I vaguely remember how about three years ago I thought that I am dumb and/or
the documentation is wrong when I tried to use the `sequential_or` but ended
with some workaround.
There are three possible fixes:
- This one
- Make the original `any_ns` and `any_if_ns` strict ordered
(could potentially make permutations operator slower)
- Break the `any_ns` and `any_if_ns` API and somehow generalize the code
