The special handling was used instead of removing references from the
`make_attribute<T,U>::type`. Since `make_attribute` is gone the workaround is
no longer needed.
boost/spirit/home/support/utree/detail/utree_detail2.hpp(936): warning C4458: declaration of 'p' hides class member
boost/spirit/home/support/utree/utree.hpp(603): note: see declaration of 'boost::spirit::utree::p'
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.
This will allow to simplify transform_attribute (e.g. no need to handle
references anymore) and to ensure the pre/post/fail calls are made to the
same transformation.
The double conversion `spirit::string -> std::string -> spirit::string` was
happening silently in rules because of `transform_attribute` was returning
`std::string` and implicit constructor in `spirit::string`.
The mistake could be prevented if `spirit::basic_string` constructor from
derived class was explicit, but `utree_cast` uses `is_convertible` while
`is_constructible` is not implemented for C++03 (it is possible, but requires
expression SFINAE support from compiler - N2634).
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
After #456 `parse_rule` is always called with value of `rule::attribute_type&`
type. By removing attribute type deduction we also will turn any possible bug
in `transform_attribute` from a linkage to compile error.
Fixes#454
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.
The `partition_attribute` never splits a sequence into zero sized parts.
Removing the specialization simplifies an ongoing patch that will forbid
sequence into plain types parsing.
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.
The `boost/spirit/home/support/detail/lexer/serialise.hpp` header is a private header
and is not used anywhere in Spirit or Boost. No one should be affected by the change.
It looks like mismatching skipper types and `parse`/`phrase_parse` calls are
quite popular mistakes, and the actual problem is not clear for users despite
that there is a comment near the call that will fail and the hint should be
found by following to the file and line that compiler reports the error on.
When underlying iterator returns by value the corresponding position_iterator
was providing iterator_adaptor with a reference type what lead to returning
a reference to a local variable in dereference operator.
Made a custom trait because it is a way more elegant than:
```cpp
typedef typename boost::mpl::if_c<
boost::is_reference<reference>::value,
typename boost::add_reference<
typename boost::add_const<
typename boost::remove_reference<reference>::type
>::type
>::type,
typename boost::add_const<reference>::type
>::type const_reference_type;
```
Fixes https://svn.boost.org/trac10/ticket/9737.
When `min_token_id` is not a valid value for `id_type` and `first_id` is not
provided lexer constructor is triggering UB. To fix this problem, constructor
with ommited `first_id` initializes `next_token_id` directly, so if unique ids
feature is not used there is no UB.
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.
With `BOOST_SPIRIT_UNICODE` defined Clang, MinGW and Cygwin were using `wchar_t`.
I have switched to OS detection with `_WIN32`, it will give the right results for
most compilers except Cygwin.
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.
This applies the fix in 6d6f40c3e5 to all BOOST_NOEXCEPT_IF statements in
variant.cpp. I have trouple compiling a toy project with VS2015, as these
noexcept if statements fails to compile.
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
Boost's iterator.hpp is deprecated, too. It does nothing but pulling std::iterator into namespace boost and including standard headers 'iterator' and 'cstddef'. Therefore get rid of all of that and replace inheritance by lifting std::iterator's members into the derived class.
.\boost/spirit/home/x3/core/detail/parse_into_container.hpp(299): error C2752: 'boost::spirit::x3::detail::parse_into_container_impl<Parser,Context,RContext,void>': more than one partial specialization matches the template argument list
A single item sequences like `fusion::vector<T>` will be passed through,
while fusion iterators, fusion iterator range or view of size one will
be dereferenced before passing to underlying parsers of sequence parser.
