`rule` now resolves the parse function using concepts, providing
significantly faster compile time & better errors.
`core/error_handler_types.hpp`: New header to separate enum
definition.
`annotate_on_success`: Modernized.
`on_error` and `on_success` now only accepts const iterators.
This is a breaking change, but we should apply this immediately
due to the reasons described below.
Historically, Spirit has passed mutable lvalue references of the
*internal* iterators to the `on_success`/`on_error` handlers. This
behavior was semantically a mistake, because:
(1) `on_success`/`on_error` mechanism was designed to be
grammar-agnostic, and
(2) it does not make sense to modify the grammar-specific
iterator on the grammar-agnostic callback.
Furthermore, any modification to X3's internal iterator variables
may invoke undefined behavior, since we had never provided any
kind of guarantee on how those variables are processed in X3's
implementation details.
In other words, I consider the old behavior as a serious BUG
that involves undefined behavior which may even lead to
security issues.
`BOOST_SPIRIT_DECLARE`: Deprecated regarding compile-time slowness
of `BOOST_PP_SEQ_FOR_EACH`.
`BOOST_SPIRIT_DEFINE`: Ditto.
`BOOST_SPIRIT_INSTANTIATE`: Deprecated because the name was not
correctly prefixed with `X3_`.
`BOOST_SPIRIT_X3_DECLARE`: New macro with correctly prefixed name.
`BOOST_SPIRIT_X3_DEFINE`: Ditto.
`BOOST_SPIRIT_X3_INSTANTIATE`: Ditto.
This will deal with linking problems when rule attribute type is not the same
as the actual attribute type. It will not harm anyone as the transformation
after parse_rule will just pass-through the attribute because it will be the
same there. It will also do not alter rule_definition parsing so other usages
are still valid.
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.
When a rule has no attribute (leaves `Attribute` template parameter as default)
the `BOOST_SPIRIT_INSTANTIATE` macro instantiates a `parse_rule` helper function
with a wrong signature because `parse`, `phrase_parse`, and `skip_over` pass as
the attribute `unused` variable which deduces to `unused_type const&` type, but
`BOOST_SPIRIT_INSTANTIATE` instantiates `parse_rule` with `unused_type&` type.
