The IgnoreOverflowDigits=true parser always succeeds and because of that it
expects from the digits parser that a number passed as inout argument will be
changed only on success.
Changed negative_accumulator and X3 for consistency.
It was poorly documented and never worked correctly. None of atof, strtof, and
input streams are accepting such values. Fixing it would be a bigger breaking
change than removing it.
Fixes#415, addresses #163 and https://svn.boost.org/trac10/ticket/8699
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.
There is a mistake in `make_attribute` trait that leads to synthesization and
immediately throwing out an attribue, so rule context always was unused_type
when actual attribute is unused_type (added test for this case). Instead of
fixing `make_attribute` trait I just completely removed synthesization in
rule by removing `make_attribute` trait usage (the traits could be removed
after a simple change in 'action' parser). I think the change is better
than fixing the trait because it removes excessive attribute default
construction in every rule and makes rule almost free to use.
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.
Not intrusive. Significantly speeds up tests on MSVC (for about 3 times).
Finally solves exceeding build time limits on CI with MSVC compilers.
Did not set up PCH for X3, it is fast as-is (tooks only about 2 minutes).
Repository tests reuse PCH from Qi/Karma tests.
It will allow to test `extract_int` properly.
Replacing `boost::integer_traits` with `std::numeric_limits` will not hurt
performance because even MSVC 9/GCC 4.1/Clang 3.0 folds `min`/`max` calls
to a constant at compile time and since C++11 they are even constexpr.
Spirit were assuming that wchar_t is 32-bit and the content is UCS-4.
It is wrong, the actual representation is implementation defined [lex.ccon]/6.
However, on most Unix platforms this assumption is valid and gives the
expected outcome, but on Windows wchar_t is 16-bit and the content is UTF-16.
Domain-agnostic class template partial specializations and
type agnostic domain partial specializations are ambious.
To resolve the ambiguity type agnostic domain partial
specializations are dispatched via intermediate type.
The `extract_from_attribute` returns a reference to a temporary
value produced by calling Fusion ADT adapted sequence getter that
returns by value.
Was reported 6 years ago https://svn.boost.org/trac10/ticket/6126
