And again it's me. This time with a C++ template problem. When I say
template<> Bar FooTo<Bar>(const Foo& foo);
which is a specializazion of
template<class T> T FooTo(const Foo& foo);
then it (the upper line) won't get parsed. I changed func-decl:
(original commented out, changed version below)
#func-decl : opt-stars opt-class opt-destructor functionname opt-under-p
arg-list
# opt-post-fcn-modifiers
# opt-throw
# opt-initializers
# fun-or-proto-end
# ( ,$4 'function
# ;; Extra stuff goes in here.
# ;; Continue with the stuff we found in
# ;; this definition
# $2 $3 $6 $8 $7 ,$1 ,$10)
# ;
func-decl : opt-stars opt-class opt-destructor functionname
opt-template-specifier opt-under-p arg-list
opt-post-fcn-modifiers
opt-throw
opt-initializers
fun-or-proto-end
( ,$4 'function
;; Extra stuff goes in here.
;; Continue with the stuff we found in
;; this definition
$2 $3 $7 $9 $8 ,$1 ,$11)
;
I added opt-template-specifier because it seemed the easiest thing to
do. And it seems to work. As usual, beware of changes done by him who
had no idea of what he was doing :).
Btw, for people not that acquainted with C++ templates, the <Bar> in
FooToo<Bar> is necessary in C++ because the return type is not
considered when inferring types.
And then there is another problem. Put all this in a namespace and it
doesn't work. More specifically, write
namespace Blah {
template<class T> T FooTo(const Foo& foo) throw(IllegalFormat);
template<> Bar FooTo<Bar>(const Foo& foo);
}
and semantic-show-unmatched-syntax-mode highlights both leading
template<class T> and template<>.
And another little one. When I write
void f(const Foo* const& foo);
(which looks strange but was necesary when specifying a template, I just
shortened it to have a small example), semantic gets confused and parses
two arguments (unmatched syntax is "* const&"):
(("f" function
("void")
(("" variable "Foo" nil
((const . t))
nil nil #<extent [8, 18)
semantic 0x84000f0 in buffer type.cc>)
("" variable "foo" nil nil nil nil #<extent [26, 30)
semantic 0x84000b8 in buffer type.cc>))
((prototype . t))
nil nil #<extent [1, 31)
semantic 0x8400128 in buffer type.cc>))
Unfortunately, during the next couple of days I won't have any more time
to investigate the two latter problems. But maybe my hacks are a
nuisance anyway :).
Regards, Thomas.
--
Thomas Maier <T.Maier@...>
|