I have not touch examples because they are not affecting Spirit usage and testing dependencies, and modernizing them also seems like a waste of time when we encourage to start new projects with X3 instead of Qi.
A skipper does this already and Spirit usually does not roll back skipper work. When there is no skipper, skipping whitespaces is absolutely wrong thing to do. For example, an error points to an end of the word where an additional input is expected, but there are whitespaces after it.
The `skip_whitespace`/`skip_non_whitespace` were removed since they are not used anymore, and because they are also could trigger UB on a particular input due to unsafe `std::isspace` usage.
Removes flat sequence parser through optional to fix:
* Non-flat `tuple<..., optional<tuple<...>>, ...>` parsing.
* Optional container parsing when it is a part of the sequence and the optional parser subject is a sequence too.
The removed test cases are invalid (see #664) variants of flat through optional. There are a valid ones (like `int_ >> -(int_ >> int_)` into `tuple<int, optional<int>, optional<int>>`) that would be broken after the change, but at the moment I do not have a popper way to make it work.
It is hard to not forget to keep in sync these while anyone interested could simply go to the macro definition, moreover users should not rely on the implementation details and telling this info may make it seem like `parse_rule` is a public API.
When a rule placeholder constructed and immediately consumed it cannot be used recursively, that's why the rule definition injection into a parser context can be skipped.
This optimization has a huge impact on compile times because immediate rules are commonly used to cast an attribute like `as`/`attr_cast` does in Qi.
Addresses annoying conversion warnings in expressions like `byte(0)` where `int` to `uint8_t` conversion happened deeply is Spirit rather than in a user code.
It might cost us backward compatibility with ancient compilers, exotic platforms,
and yield a performance difference on MSVC, but Boost.Math is C++11 now, and
Clang-cl can (or even should) be used instead of MSVC where performance matters.
