Syntax Checker issues

fujie wrote on Tue Jul 18 00:23:14 MEST 2006:

Hello,

I was wondering about the syntax checker.  It seems a bit buggy, but it
could just be me.  I will explain my problem with an example.  Let's say
I have two modules A.pm and B.pm, and module A has "use B" statement.  This
statement will report an Error due to "so called" existing errors in module
B.  So I go check the errors in module B and fix them (or find that there
are none).  And now I go back to module A and the "use B" statement still
reports an error, even though I have fixed B.pm to NOT report any errors.
 (I have done numerous "Clean Projects").

This is very odd.  Because sometimes I will open and close an erroneous
module and that will "magically" fix the error (I don't know why).

Does anyone else have similar problems?  Are there still bugs being worked
out with the syntax checker?

Thanks

Fuji

pacanukeha wrote on Tue Jul 18 01:09:58 MEST 2006:

Yeah, I get this problem.  perl -c on the commandline shows no problems.
 Program executed in context generates no problems.  Project|Clean sometimes
fixes it, sometimes doesn't.

jploski wrote on Thu Jul 20 21:57:24 MEST 2006:

Currently, syntax checking is done on a per-file basis using "perl -c".
When you open/save a file, the syntax check is performed on it automatically
in the background. This syntax check begins by removing all error markers
from the checked file. After that, the error markers are added to all files
about which "perl -c" is complaining (which might as well be other files
than the checked file).

This algorithm's intent is to assign markers to files on which errors are
reported rather than the files whose checking reports errors. However, it
is imperfect because in some cases it leads to disappearing of error markers.
You can have a situation in which you have a script foo.pl using module
Bar.pm, and when you run "perl -c" on foo.pl you get the interpreter complaining
about errors in Bar.pm, but when you run "perl -c" on Bar.pm, it says the
file itself is ok. In this situation, reopening Bar.pm in EPIC will clear
the markers which should stay because they were actually contributed by
a check of foo.pl. On the other hand, if you delete foo.pl from the project,
its contributed markers on Bar.pm should disappear (unless other scripts
are also contributing them). This dependency tracking between error markers
and source files which caused their appearance is not implemented. It would
require major work to get it done right.

I can imagine that the problems also occurs upon "Project/Clean" sometimes
because the order in which the files are checked plays a role, but it is
not constrained by EPIC. I would be interested in concrete (small) examples
of projects in which this is happening because implementing some ordering
heuristics might be feasible.

In general, these problems will happen if you have missing modules in the
@INC path (e.g., some modules reference other modules which themselves reference
non-existing modules). After you have sorted out the @INC path, the problems
should no longer occur. At this time, running perl -c manually on all your
files is a recommended way of sorting out this puzzle. (I hope you are using
epic-devel; the handling of @INC path in 'stable'/'testing' is buggy).