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
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_'
According to spirit document,
"All numeric parsers check for overflow conditions based on the type T the corresponding uint_parser<> has been instantiated with. If the parsed number overflows this type the parsing fails. Please be aware that the overflow check is not based on the type of the supplied attribute but solely depends on the template parameter T."
the valid input range of x3::uint_parser<T> should be 0 - std::numeric_limits<T>::max(). However, the current implementation takes values from std::numeric_limits<T>::max()+1 - std::numeric_limits<std::make_unsigned_t<T>>::max() also as valid input.
