The Spirit typeof tests seem to just include the registration files. Is more comprehensive testing being planned? Regards, Arkadiy
Arkadiy Vertleyb wrote:
The Spirit typeof tests seem to just include the registration files. Is more comprehensive testing being planned?
<cite -- email correspondence on testing typeof registration> Joel de Guzman wrote:
Tobias Schwinger wrote:
Joel de Guzman wrote:
Tobias Schwinger wrote:
Is there a way to tweak the existing test suite to apply Typeof to the types involved?
Hmmm...I'm not sure if that's a good idea --but I'm not sure. I'm afraid of entanglement. Wouldn't it be better to have separate tests?
I just added simple separate tests that just include Spirit plus typeof
cool!
headers to ensure none of the forward declarations (those in the typeof.hpp files which are not tied to the component header) have been broken. These tests also catch typos in the registration. If we want to find forgotten registrations, however, the tests must cover all there is in Spirit -- but we can also wait for someone to complain, I figure (and -on second thought- I think I like it).
I think this is the right way to go. I'm not quite fond of the carpet bombing approach to testing anyway. If we add typeof tests to all the tests, then that would amount to 2X testing time (more considering the compile time of Boost.Typeof is relatively not insignificant). A more focused set of tests is my preference. In fact, when we have Spirit-2, I'd re-focus those tests we already have there. It's already taking up too much testing resources as it was.
</cite> The infrastructure beyond registration (to actually utilizy typeof support for building grammars) boost/spirit/utility/rule_parser.hpp libs/spirit/example/techniques/no_rules_with_typeof/* is still in experimental state; there is no documentation except a preliminary manual in the header, there are no tests except the examples and right now even these few require a *very* decent compiler to work (GCC 3.4 emulated/native Typeof and VC8 with some issues left work. VC7.1 seems to randomly ICE inside Typeof in some -sometimes surprisingly simple- cases, so if you're looking for a new challenge, please go ahead ;-) ). Regards, Tobias
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote
there are no tests except the examples and right now even these few require a *very* decent compiler to work (GCC 3.4 emulated/native Typeof and VC8 with some issues left work. VC7.1 seems to randomly ICE inside Typeof in some -sometimes surprisingly simple- cases
I would like to take a look at them (not that I am expecting to be able to fix ICEs, though). Are these ICEs related to types used or to any particular context the typeof is used from? Regards, Arkadiy
Arkadiy Vertleyb wrote:
I would like to take a look at them (not that I am expecting to be able to fix ICEs, though).
Are these ICEs related to types used or to any particular context the typeof is used from?
The opaque_rule_parser example (only uses non-templated typeof) works. The rule_parser_1_1 example makes VC7.1 ICE in the first, very simple rule (it uses non-templated typeof). The rule_parser_1_2 example, which uses some really tricky stuff (and both templated and non-templated typeof), works fine. The rule_parser_2_1 example works too (it requires native mode to compile because LIMIT_SIZE == 100 is beyond the limit). The rule_parser_2_2 fails in the third rule (maybe because of the self-reference or maybe just for the same obscure reasons rule_parser_1_1 does). For the examples that ICE it does not matter whether BOOST_TYPEOF_EMULATION is defined or not. Regards, Tobias
On 2/22/06, Tobias Schwinger <tschwinger@neoscientists.org> wrote:
Arkadiy Vertleyb wrote:
I would like to take a look at them (not that I am expecting to be able to fix ICEs, though).
Are these ICEs related to types used or to any particular context the typeof is used from?
The opaque_rule_parser example (only uses non-templated typeof) works.
The rule_parser_1_1 example makes VC7.1 ICE in the first, very simple rule (it uses non-templated typeof).
This is not a problem in BOOST_TYPEOF. The following code replicates the ICE under VC7.1: #include <boost/spirit/core.hpp> #include <boost/spirit/utility/confix.hpp> using namespace boost::spirit; template<typename T> void test(const T&) {} int main() { test( confix_p("//",*anychar_p,eol_p) | confix_p("/*",*anychar_p,"*/") | space_p ); return 0; } Regards, Peder
The rule_parser_1_2 example, which uses some really tricky stuff (and both templated and non-templated typeof), works fine.
The rule_parser_2_1 example works too (it requires native mode to compile because LIMIT_SIZE == 100 is beyond the limit).
The rule_parser_2_2 fails in the third rule (maybe because of the self-reference or maybe just for the same obscure reasons rule_parser_1_1 does).
For the examples that ICE it does not matter whether BOOST_TYPEOF_EMULATION is defined or not.
Regards,
Tobias
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt wrote:
This is not a problem in BOOST_TYPEOF.
Well, I never said it was -- it's a VC7.1 problem of course ;-). It's a confix_p with VC7.1 -- that's why I cross post to spirit.devel. If it's unfixable it would probably be a good idea to have a portability note in the docuementation.
The following code replicates the ICE under VC7.1:
Minimized further:
#include <boost/spirit/core.hpp> #include <boost/spirit/utility/confix.hpp>
using namespace boost::spirit; template<typename T> void test(const T&) {}
int main() { test( confix_p("//",*anychar_p,eol_p) <snip> ); return 0; }
Using confix_p(str_p("//"),*anychar_p,eol_p) melts the ICE. Regards, Tobias
Tobias Schwinger wrote:
Peder Holt wrote:
This is not a problem in BOOST_TYPEOF.
Well, I never said it was -- it's a VC7.1 problem of course ;-).
It's a confix_p with VC7.1 -- that's why I cross post to spirit.devel. If it's unfixable it would probably be a good idea to have a portability note in the docuementation.
Yes we are aware of this problem. With VC7.1, I tend to avoid the confix stuff. The problem is somewhere in the complexity of the meta facilities of Spirit. Hopefully, this will go away with Spirit-2. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Tobias Schwinger wrote:
It's confix_p with VC7.1 -- that's why I cross post to spirit.devel. If it's unfixable it would probably be a good idea to have a portability note in the docuementation.
Yes we are aware of this problem. With VC7.1, I tend to avoid the confix stuff. The problem is somewhere in the complexity of the meta facilities of Spirit. Hopefully, this will go away with Spirit-2.
Maybe having an vague idea what causes the problem can help. Does anyone know more about it? Here's my attempt of reconstructing another instance that occurs when int_p[& do_int] is used in the wrong context (a case without confix stuff and hopefully less "meta depth"). // define BOOM e [1;3] to make VC1 ICE #include <cstddef> #include <iostream> #include <boost/spirit/core.hpp> void do_int(int) { } // using a functor instead works template<std::size_t> struct take_size_t { typedef void type; }; using namespace boost::spirit; #if ! defined BOOM template<typename T> struct wrap { // OK static const std::size_t value = sizeof(int_p[& do_int]); // wrapping the expression (see BOOM = { 2,3 }) also works typedef typename take_size_t<value>::type type; }; #elif BOOM == 1 template<typename T> struct wrap { // overloaded function: illegal sizeof operand // note: the function is *not* overloaded typedef take_size_t< sizeof( int_p[& do_int] ) >::type type; }; #elif BOOM == 2 template<typename U> U const & const_ref_bind(U const & u) { return u; } template<typename T> struct wrap { // ICE typedef take_size_t< sizeof(const_ref_bind(int_p[& do_int])) >::type type; }; #else // BOOM == 3 template<typename T, typename U> U const & depend_on_type(U const & u) { return u; } template<typename T> struct wrap { // ICE typedef typename take_size_t< sizeof(depend_on_type<T>(int_p[& do_int])) >::type type; }; #endif Thanks, Tobias
In confix_parser_gen: Adding another level of indirection solves the problem: template<typename StartT, typename ExprT, typename EndT> confix_parser< typename as_parser<StartT>::type, <- VC7.1 ICEs on these typename as_parser<ExprT>::type, typename as_parser<EndT>::type, typename as_parser<ExprT>::type::parser_category_t, NestedT, LexemeT > operator()( StartT const &start_, ExprT const &expr_, EndT const &end_) const Filtering the confix_parser into type-generating template, result_type, solves this ICE. template<typename StartT, typename ExprT, typename EndT> struct result_type { typedef confix_parser< typename as_parser<StartT>::type, typename as_parser<ExprT>::type, typename as_parser<EndT>::type, typename as_parser<ExprT>::type::parser_category_t, NestedT, LexemeT > type; }; template<typename StartT, typename ExprT, typename EndT> typename result_type<StartT,ExprT,EndT>::type operator()( StartT const &start_, ExprT const &expr_, EndT const &end_) const Now rule_parser_1_1 passes without problems. Attached is a patch with this fix. Regards, Peder
participants (4)
-
Arkadiy Vertleyb -
Joel de Guzman -
Peder Holt -
Tobias Schwinger