{ parsing problem
sebbu2 opened this issue · comments
I tried to compile a (big, c++) project, and got that PARSING error in a standard C++ header:
In state 1138, I expected one of these tokens:
try, {,
/usr/include/c++/4.6/x86_64-linux-gnu/bits/c++config.h:154:1: Parse error (state 1138) at {
I think there is some inconsistencies between the #define in ast and elkhound
It would sure help if you would provide a minimized version of the input that produces the same error. If this is challenging, consider using http://delta.tigris.org/ .
It would sure help if you would provide a minimized version of the
input that produces the same error. If this is challenging, consider
using http://delta.tigris.org/ .
On Sat, May 21, 2011 at 6:44 AM, sebbu2
reply@reply.github.com
wrote:
I tried to compile a (big, c++) project, and got that PARSING error in a standard C++ header:
In state 1138, I expected one of these tokens:
try, {,
/usr/include/c++/4.6/x86_64-linux-gnu/bits/c++config.h:154:1: Parse error (state 1138) at {I think there is some inconsistencies between the #define in ast and elkhound
Reply to this email directly or view it on GitHub:
#3
#include <stdio.h>
int printf(const char *format, ...);
namespace perso {
void test();
}
void perso::test() {
printf("test\n");
}
int main(void) {
perso::test();
return 0;
}
this code works if i run qual directly, but doesn't work if i run g++ -E before (it show another bug on a throw directive).
No, you don't understand. I need to see exactly the raw input to
Elsa that is causing the problem. You send me a file and and say that
this files does not cause a problem! But if you run it through the
preprocessor, then it does. Well, I have no idea what your system
stdio.h looks like!
Do whatever you do, including running it through the preprocessor,
then confirm the problem in the raw output, then minimize the output
so that (1) it is still a legal C++ file (gcc still compiles it) and
(2) it still reproduces the problem, then send me THAT.
Please put yourself in my position and think about the fact that I
can't fix the bug until I know exactly what the bug is and that
further your system does not have the same configuration, headers, etc
that mine does. Use your head.
On Sat, May 21, 2011 at 1:48 PM, sebbu2
reply@reply.github.com
wrote:
#include <stdio.h>
int printf(const char *format, ...);
namespace perso {
void test();
}
void perso::test() {
printf("test\n");
}
int main(void) {
perso::test();
return 0;
}this code works if i run qual directly, but doesn't work if i run g++ -E before (it show another bug on a throw directive).
Reply to this email directly or view it on GitHub:
#3 (comment)
# 1 "test2.cpp"
# 1 ""
# 1 ""
# 1 "test2.cpp"
# 153 "/usr/include/c++/4.6/x86_64-linux-gnu/bits/c++config.h" 3
namespace std
{
typedef long unsigned int size_t;
typedef long int ptrdiff_t;
}
this code is the exact portion which show the bug i found
typedef struct {
}
__mbstate_t;
namespace __gnu_cxx __attribute__ ((__visibility__ ("default"))) {
}
namespace std __attribute__ ((__visibility__ ("default"))) {
template<class _Sp, class _Tp> struct __traitor {
};
template<typename _Tp> struct __is_integer {
};
template<typename _Tp> struct __is_floating {
};
template<typename _Tp> struct __is_pointer {
};
template<typename _Tp> struct __is_arithmetic : public __traitor<__is_integer<_Tp>, __is_floating<_Tp> > {
};
template<typename _Tp> struct __is_scalar : public __traitor<__is_arithmetic<_Tp>, __is_pointer<_Tp> > {
};
}
namespace __gnu_cxx __attribute__ ((__visibility__ ("default"))) {
template<bool, typename> struct __enable_if {
};
}
namespace std __attribute__ ((__visibility__ ("default"))) {
template<typename _OutputIterator, typename _Size, typename _Tp> inline typename __gnu_cxx::__enable_if<__is_scalar<_Tp>::__value, _OutputIterator>::__type __fill_n_a(_OutputIterator __first, _Size __n, const _Tp& __value) {
const _Tp __tmp = __value;
for (__decltype(__n + 0) __niter = __n;
__niter > 0;
--__niter, ++__first) *__first = __tmp;
}
}This C++ code (apprently using some C++0x features, but coming only from libstdc++, not user code) doesn't parse using oink.
My version of gcc compiles this just fine:
namespace std
{
typedef long unsigned int size_t;
typedef long int ptrdiff_t;
}
g++ --version
i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Please send me a file that does not compile and the output when you
build it with g++.
On Sat, May 21, 2011 at 1:53 PM, sebbu2
reply@reply.github.com
wrote:
1 "test2.cpp"
1 ""
1 ""
1 "test2.cpp"
153 "/usr/include/c++/4.6/x86_64-linux-gnu/bits/c++config.h" 3
namespace std
{
typedef long unsigned int size_t;
typedef long int ptrdiff_t;
}this code is the exact portion which show the bug i found
Reply to this email directly or view it on GitHub:
#3 (comment)
Ah, sorry. Your probably meant that oink has a problem with it. I
don't see it.
../oink -fo-print-stages sebbu2.cc
%% [ 0 ms] [4112 MB] oink stage: init
%% [ 0 ms] [4112 MB] oink stage: parse
%% [ 1 ms] [4112 MB] oink stage: typecheck
%% [ 3 ms] [4112 MB] oink stage: elaborate
%% [ 3 ms] [4112 MB] oink stage: mark real vars
%% [ 5 ms] [4112 MB] oink stage: filter stage
%% [ 6 ms] [4112 MB] oink stage: register vars
%% [ 9 ms] [4112 MB] oink stage: value
%% [ 9 ms] [4112 MB] oink stage: integrity
%% [ 9 ms] [4112 MB] oink stage: deserialize
%% [ 9 ms] [4112 MB] oink stage: simple dataflow
%% [ 9 ms] [4112 MB] oink stage: check for used vars
%% [ 9 ms] [4112 MB] oink stage: link
%% [ 10 ms] [4112 MB] oink stage: cleanup
On Sat, May 21, 2011 at 1:53 PM, sebbu2
reply@reply.github.com
wrote:
1 "test2.cpp"
1 ""
1 ""
1 "test2.cpp"
153 "/usr/include/c++/4.6/x86_64-linux-gnu/bits/c++config.h" 3
namespace std
{
typedef long unsigned int size_t;
typedef long int ptrdiff_t;
}this code is the exact portion which show the bug i found
Reply to this email directly or view it on GitHub:
#3 (comment)
First, you can't take the raw output of delta and just send it to me.
There is more you have to do by hand to get it minimal.
Second, when you used delta, did you be sure to do a controlled
experiment as it says in the documentation? That means that the test
that delta is repeating should test that (1) the file DOES compile
with gcc and (2) does NOT pass elsa/oink. This file you sent me
does not seem to compile using gcc.
Daniel
On Fri, May 27, 2011 at 2:30 AM, sebbu2
reply@reply.github.com
wrote:
typedef struct { } __mbstate_t; namespace __gnu_cxx __attribute__ ((__visibility__ ("default"))) { } namespace std __attribute__ ((__visibility__ ("default"))) { template<class _Sp, class _Tp> struct __traitor { }; template<typename _Tp> struct __is_integer { }; template<typename _Tp> struct __is_floating { }; template<typename _Tp> struct __is_pointer { }; template<typename _Tp> struct __is_arithmetic : public __traitor<__is_integer<_Tp>, __is_floating<_Tp> > { }; template<typename _Tp> struct __is_scalar : public __traitor<__is_arithmetic<_Tp>, __is_pointer<_Tp> > { }; } namespace __gnu_cxx __attribute__ ((__visibility__ ("default"))) { template<bool, typename> struct __enable_if { }; } namespace std __attribute__ ((__visibility__ ("default"))) { template<typename _OutputIterator, typename _Size, typename _Tp> inline typename __gnu_cxx::__enable_if<__is_scalar<_Tp>::__value, _OutputIterator>::__type __fill_n_a(_OutputIterator __first, _Size __n, const _Tp& __value) { const _Tp __tmp = __value; for (__decltype(__n + 0) __niter = __n; __niter > 0; --__niter, ++__first) *__first = __tmp; } }This C++ code (apprently using some C++0x features, but coming only from libstdc++, not user code) doesn't parse using oink.
Reply to this email directly or view it on GitHub:
#3 (comment)