Looking at the test1.v parsing I saw a first issue with an excessive nonterminal decomposition, affecting the number base identification production rules, like in
decimal_base
: TICK OPT_S D
separating the optional [sS]? from the surrounding tokens, the [sS]? turns to be match the empty string also when it should not. Matching [sS] with the empty string in the context of
'[sS]?[bBoOdDhH]
would be fine, but it seems that the LALR parsers parses that [sS]? occurrence much more widely.
A very simple solution should be something like
% : TICK OPT_S D
: '[sS]?[dD]"
or maybe to introduce new tokens for regexps like the one above.
I'll try that next.
[NOTE: actually, in about 17 years of Verilog code inspectioning, I NEVER saw an [sS] used in in that context; Nonetheless it is in the BNF, and I'd like to keep it.]
Last edit: Andrea Fedeli 2013-02-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am now pretty sure sverilog.wy parsing, for a yet unknown reasons, harms some internal structure so that subsequent semantic-grammar-create-package do not work properly, generating floods of syntax error messages, neither on expected to be correct grammars (I reproduced this behavior first parsing sverilog.wy, then parsing java.wy vanilla taken from bazaar cedet trunk).
Extending the Messages log with
(setq message-log-max 10000) I succeeded seeing the first syntax error:
It happens on the first occurrence of the < token, typically on
%type <...
Actually this does /not/ happen the same of different platforms:
on Mint 14.1 + GNU Emacs 24.2 compiled from sources + Bazaar Cedet trunk works fine, with no syntax error report.
On Lion + GNU Emacs 24.2.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2012-08-27 on bob.porkrind.org + Bazaar Cedet trunk I have the syntax error flood.
Last edit: Andrea Fedeli 2013-02-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The situation seems to be worse: on Lion, there is something weird linked to the usage of the cedet bzr trunk to date (latest bzr update: 22.2.2013), independently on the sverilog.wy preliminary parsing.
(3) Load a wisent file in the trunk, say, python.wy.
Wait a bit, and you'll get the flood...
It seems to be something related the usage of wisent-parse-toggle-verbose-flag; next step should be to figure out whether that function call just reveals the issue, or rather causes it.
Last edit: Andrea Fedeli 2013-02-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I investigated a bit, and found wisent-parse-toggle-verbose-flag just reveals the flood, which is otherwise simply silently there underneath.
wisent-parse-toggle-verbose-flag toggles wisent-parse-verbose-flag, on its turn enabling the output of wisent-message, i.e.: the default function behind wisent-error-function.
Interesting! Maybe it is time for a message to the CEDET mailing list. I'd better check nobody else already raised it, ahead.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looking at the test1.v parsing I saw a first issue with an excessive nonterminal decomposition, affecting the number base identification production rules, like in
decimal_base
: TICK OPT_S D
separating the optional [sS]? from the surrounding tokens, the [sS]? turns to be match the empty string also when it should not. Matching [sS] with the empty string in the context of
'[sS]?[bBoOdDhH]
would be fine, but it seems that the LALR parsers parses that [sS]? occurrence much more widely.
A very simple solution should be something like
% : TICK OPT_S D
: '[sS]?[dD]"
or maybe to introduce new tokens for regexps like the one above.
I'll try that next.
[NOTE: actually, in about 17 years of Verilog code inspectioning, I NEVER saw an [sS] used in in that context; Nonetheless it is in the BNF, and I'd like to keep it.]
Last edit: Andrea Fedeli 2013-02-21
I am now pretty sure sverilog.wy parsing, for a yet unknown reasons, harms some internal structure so that subsequent semantic-grammar-create-package do not work properly, generating floods of syntax error messages, neither on expected to be correct grammars (I reproduced this behavior first parsing sverilog.wy, then parsing java.wy vanilla taken from bazaar cedet trunk).
Extending the Messages log with
(setq message-log-max 10000) I succeeded seeing the first syntax error:
It happens on the first occurrence of the < token, typically on
%type <...
Actually this does /not/ happen the same of different platforms:
on Mint 14.1 + GNU Emacs 24.2 compiled from sources + Bazaar Cedet trunk works fine, with no syntax error report.
On Lion + GNU Emacs 24.2.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2012-08-27 on bob.porkrind.org + Bazaar Cedet trunk I have the syntax error flood.
Last edit: Andrea Fedeli 2013-02-22
The situation seems to be worse: on Lion, there is something weird linked to the usage of the cedet bzr trunk to date (latest bzr update: 22.2.2013), independently on the sverilog.wy preliminary parsing.
Preparation:
(1) in the .emacs /just/ the following lines:
(setq message-log-max 10000)
(load-file "<path_to_your_cedet_trunk>/cedet-devel-load.el")
(require 'semantic/wisent/comp)
(semantic-mode 1)
(wisent-parse-toggle-verbose-flag)
(2) rm -rf ~/.emacs.d/semantic*
rm ~/.emacs.desktop
(3) Load a wisent file in the trunk, say, python.wy.
Wait a bit, and you'll get the flood...
It seems to be something related the usage of wisent-parse-toggle-verbose-flag; next step should be to figure out whether that function call just reveals the issue, or rather causes it.
Last edit: Andrea Fedeli 2013-02-22
Reproduce also on Mint 14.1 + GNU Emacs 24.2 compiled from sources + Bazaar Cedet trunk:
Loading calc.wy after
(wisent-parse-verbose-flag)
produces
wisent-parse-stream: #<buffer calc.wy=""> - Not enough arguments for format string [3 times]
Syntax error, unexpected CHARACTER@1565("'='"), expecting DEFAULT-PREC, NO-DEFAULT-PREC, KEYWORD, LANGUAGEMODE, LEFT, NONASSOC, PACKAGE, PROVIDE, PUT, QUOTEMODE, RIGHT, SCOPESTART, START, TOKEN, TYPE, USE-MACROS, SYMBOL, PERCENT_PERCENT, PROLOGUE, EPILOGUE [2 times]
: : :
So, this time the parser goes beyond the first '<' occurrence (there is a
%token <number> NUM
two lines above the '=')
?
OK, I investigated a bit, and found wisent-parse-toggle-verbose-flag just reveals the flood, which is otherwise simply silently there underneath.
wisent-parse-toggle-verbose-flag toggles wisent-parse-verbose-flag, on its turn enabling the output of wisent-message, i.e.: the default function behind wisent-error-function.
Interesting! Maybe it is time for a message to the CEDET mailing list. I'd better check nobody else already raised it, ahead.