Actually the warning here is a sign of bad design. Attribute should go directly
to sink, and there will be no truncation warning except a situation when sink
is not wide enough for attribute or binded value.
Closes https://svn.boost.org/trac10/ticket/11540.
Actually this should have been caught by `regression_matlib_generate_switch`
test, but it is not complex enough to cover all cases. We do not have the
coverage reports yet, but the fix is trivial so I think it is ok.
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.
After two hours of fighting with the optimizer, I happily drew attention to
this little nifty bitwise operator in `any_if_ns` function.
Explanation of the bug: bitwise inclusive OR operator is not a sequence point
(per chapter §5.13 of C++14 standard), that's why at compiling the expression
`a() | b() | ... | z()` optimizer is allowed to rearrange the execution order
of the functions `a`, `b` ... `z`.
There is high chance that a lot of people were misguided by the bug and chose
not to use `sequential_or`.
I vaguely remember how about three years ago I thought that I am dumb and/or
the documentation is wrong when I tried to use the `sequential_or` but ended
with some workaround.
There are three possible fixes:
- This one
- Make the original `any_ns` and `any_if_ns` strict ordered
(could potentially make permutations operator slower)
- Break the `any_ns` and `any_if_ns` API and somehow generalize the code
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.
It took me 3 days of pulling my hair to debug and fix the bug. The subrule's
author put a big bomb under it and I caught the exposition only in a single
test, with modern versions of Clang/GCC and enabled optimizations (most of
boost regression test runners does not use `variant=release`). Valgrind did
not catch any problems. Enabling address sanitizer causes the bug to disappear
(now I understand why, it places big gaps between stack pointers).
`-fsanitize-address-use-after-scope` catches the bug, but I have discovered
that it is turned off in Clang by default after already having a repro.
The bug could be easily reproduced if you use any parser that invalidates
it's state in the destructor.
I used `literal_char` with added `~literal_char() { ch = char_type(0); }`.
Reproduction code:
```cpp
rule<char const*> r;
subrule<0> entry;
r = (entry = 'a');
BOOST_TEST(test("a", r));
```
It will fail because after assignment to `r` a temporary `subrule_group` is
destroyed and rule is binded to the already destroyed object.
The cause is in usage of `reference` parser. I am 100% sure the code was
copy-pasted from `rule`/`grammar`. They store an expression within their
body, while `subrule` actually used only as a placeholder.
I have split `subrule_group` into an actual parser/generator that stores the
expression and a Proto terminal that contains the parser/generator.
Tested on:
- VS 2008, 2010, 2015, 2017
- Clang 3.8, 3.9, 4.0, 5.0
- GCC 4.8, 7
While I do not see usages for `bool` scanner and consider it is a dumb idea
I have not removed the test. Adding the `isblank(bool)` overload seems to me
as a reasonable compromise because it cannot break anything.
`boost::optional<T &>` has member named `argument_type`
I do not know when it did break because defining
`BOOST_OPTIONAL_CONFIG_USE_OLD_IMPLEMENTATION_OF_OPTIONAL`
does not solve the problem.
Replaces #201, fixes#249.
New `boost:optional` implementation does not contain `types` what caused
a compilation error for Qi and wrong results for Karma.
Other problem is that `not_is_variant<optional<variant<T...>>>` results in
`mpl::false_` what is unclear from it's name. While Karma relays on exactly
this behavior, Qi wrongly considers that it `mpl::true_`. I have fixed this
name ambiguity and updated Karma for the new `not_is_variant` behavior.
/usr/include/boost/spirit/home/qi/numeric/detail/real_impl.hpp:86:48: runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
With -Wlogical-op, gcc warns in radix_traits::is_valid with Radix <= 10:
```
boost/spirit/home/qi/numeric/detail/numeric_utils.hpp: In instantiation of ‘static bool boost::spirit::qi::detail::radix_traits<10u>::is_valid<char>(char)’:
[...]
boost/spirit/home/qi/numeric/detail/numeric_utils.hpp:107:31: warning: logical ‘and’ of mutually exclusive tests is always false [-Wlogical-op]
|| (ch >= 'a' && ch <= static_cast<Char>('a' + Radix -10 -1))
^
boost/spirit/home/qi/numeric/detail/numeric_utils.hpp:108:31: warning: logical ‘and’ of mutually exclusive tests is always false [-Wlogical-op]
|| (ch >= 'A' && ch <= static_cast<Char>('A' + Radix -10 -1));
^
```
Rather than suppressing the warning (https://github.com/boostorg/spirit/pull/77), refactor the test so that the warning is not triggered.
1. when used as x3::with<ID>(x), where x is an lvalue, we inject an lvalue reference of x to the context.
2. when used as x3::with<ID>(x), where x is a const lvalue, we inject a const lvalue reference of x to the context.
3. when used as x3::with<ID>(x), where x is an rvalue, we move the rvalue to the member of with_directive and inject an lvalue reference of that member to the context.
4. No copy is applied; std::ref is not needed
5. remove unused with_context
Remove a PGI-specific workaround in the functor constructor. The workaround was necessary several years ago to get class functor to compiler with PGI, but the workaround now causes compilation errors.
Unitialized rules can silently be aggregated during parser composition,
because of statics across translation units.
get_info<> has been fixed so it doesn't break. As a QoI measure, it also
added a debug assert to help diagnose the situation.
In unary_parser and binary_parser, this commit allows that debug assert
to run as early as possible (typically during program startup) so that
users will notice the initialization ordering problem.
See http://stackoverflow.com/a/41785268/85371 for the
reproducer/analysis.
Unitialized rules can silently be aggregated during parser composition,
because of statics across translation units.
Also add a debug assert diagnosing this situation.
See http://stackoverflow.com/a/41785268/85371 for the
reproducer/analysis.
Fixes the following warning message from the Intel compiler:
> boost/spirit/home/qi/numeric/detail/real_impl.hpp(34): warning #780:
> using-declaration ignored -- it refers to the current namespace
Lex is using `unique_ptr` from `movelib` and relying on a bug in it,
described in a ticket https://svn.boost.org/trac/boost/ticket/11758
Since that bug fixed in `movelib`, Lex is uncompilable.
I have simplified unique_ptr usage by the following rules:
- `delete ptr.release()` is equal to `ptr.reset()`
- `delete a.release(); a = b;` is equal to `b.swap(a); b.reset();`
Now Lex test suite compiles and runs succesfully. VC++ 6 should be
happy too despite the fact that Boost no longer supports it.
This PR contains fixes for both issues reported by Lastique and
MarcelRaad. It makes PR #197 obsolete.
Removed obsolete dependency of test/qi/expectd.cpp on
mxc/qitoo/qitoo.hpp. Was reintroduced by mistake.
Created qi/detail/expectation_failure.hpp. It defines the
expectation_failure template as a common dependency of expect directive
and expect operator. Removed expectation_failure from
operator/expect.hpp.
Changed version.hpp to 2.54. I did not notice that addl file in the
first place.
The qi_expectd.hpp was removed. qi_expect.hpp now forwards to both
directive and operator. Directive doc adjusted to reflect that change.
Lexer.qbk restored to qi develop because change is not part of expect
directive.
This change is necessary only to to maintain the independence of order
of header inclusion in qi.hpp.
Without that change, directive.hpp must be included before operator.hpp,
because the expect operator implementation was in a struct named expect
(before this change). This caused a naming conflict with the new expect
directive.
The rule_ parameter is not used in parse_rule, which BOOST_SPIRIT_DEFINE
expands to. GCC with -Wunused-parameter (indirectly activated by -Wall
-Wextra) issues a warning when a function parameter is not used in its
function body.
Silence mass MSVC-14 warnings:
boost/spirit/home/support/terminal.hpp(264): warning C4348: 'boost::spirit::terminal<boost::spirit::tag::lit>::result_helper': redefinition of default parameter: parameter 3
boost/spirit/home/support/terminal.hpp(270): note: see declaration of 'boost::spirit::terminal<boost::spirit::tag::lit>::result_helper'
boost/spirit/home/support/common_terminals.hpp(142): note: see reference to class template instantiation 'boost::spirit::terminal<boost::spirit::tag::lit>' being compiled
boost/spirit/home/support/terminal.hpp(264): warning C4348: 'boost::spirit::terminal<boost::spirit::tag::lit>::result_helper': redefinition of default parameter: parameter 4
boost/spirit/home/support/terminal.hpp(270): note: see declaration of 'boost::spirit::terminal<boost::spirit::tag::lit>::result_helper'
and so on for all terminals.
