bug in cc-mode/cc-engine/c-syntactic-re-search-forward?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
There has been an annoying bug in recent xemacs builds which (I
suspect) can be traced to the following changelog entry:<br>
<br>
<blockquote>2004-08-11&nbsp; Martin Stjernholm&nbsp; <a class="moz-txt-link-rfc2396E" href="mailto:bug...@gn...">&lt;bug...@gn...&gt;</a><br>
&nbsp;&nbsp; &nbsp;* cc-engine.el (c-syntactic-re-search-forward): Fixed bug so that<br>
&nbsp;&nbsp; &nbsp;it doesn't go past the closing paren when PAREN-LEVEL is used.<br>
&nbsp;&nbsp; &nbsp;Reordered the syntax checks to get more efficient skipping in some<br>
&nbsp;&nbsp; &nbsp;situations.<br>
</blockquote>
<br>
The symptom I see is that during edit sessions of java files (in xemacs
-vanilla), typing a line like:<br>
<blockquote>Someclass foo = <br>
</blockquote>
will result in a warning buffer being exposed with the following
message:<br>
<blockquote>(warning/warning) Error caught in
`font-lock-pre-idle-hook': (errorInvalid search limit (wrong side of
point))<br>
</blockquote>
The top of the associated backtrace looks like:<br>
<blockquote>&nbsp; # bind (standard-output stack-trace-on-signal
debug-on-signal stack-trace-on-error debug-on-error)<br>
&nbsp; signal(error ("Invalid search limit (wrong side of point)"))<br>
&nbsp; byte-code("..." [start err signal] 3)<br>
&nbsp; # bind (err start tmp search-pos state state-pos check-pos
check-state last-token-end-pos found lookbehind-submatch
not-inside-token paren-level noerror bound regexp)<br>
&nbsp; c-syntactic-re-search-forward("[;,{]" 1036 move t)<br>
&nbsp; # bind (c-record-type-identifiers c-record-ref-identifiers pos
next-pos id-start id-end paren-depth id-face got-init
c-last-identifier-range separator-prop types list limit)<br>
&nbsp; c-font-lock-declarators(1036 t nil)<br>
&nbsp; # (unwind-protect ...)<br>
&nbsp; # bind (match-data -match-end-pos- parse-sexp-lookup-properties limit)<br>
&nbsp; #&lt;compiled-function (limit) "...(93)"
[parse-sexp-lookup-properties face start end limit -match-end-pos- nil
boundp re-search-forward t 0 c-skip-comments-and-strings match-data
(...) 1 font-lock-type-face put-nonduplicable-text-property font-lock
(...) c-forward-sws (...) c-font-lock-declarators c-known-type-key
match-data match-data match-data] 5&gt;(1036)<br>
&nbsp; # bind (highlights matcher keyword nkeywords iter old-progress
progress bufname keywords case-fold-search loudly loudvar end start)<br>
&nbsp; font-lock-fontify-keywords-region(1016 1036 nil)<br>
&nbsp; # (unwind-protect ...)<br>
&nbsp; # bind (modified buffer-undo-list inhibit-read-only old-syntax-table
buffer-file-name buffer-file-truename loudly end beg)<br>
&nbsp; font-lock-default-fontify-region(1016 1036 nil)<br>
&nbsp; # bind (loudly end beg)<br>
&nbsp; font-lock-fontify-region(1016 1036)<br>
</blockquote>
<br>
The proximal cause is marked in the code below (from the 20040814
release):<br>
<blockquote>(defun c-font-lock-declarators (limit list types)<br>
&nbsp;&nbsp; ...<br>
&nbsp;&nbsp;&nbsp; (cond ((eq id-face 'font-lock-function-name-face)<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ;; Skip a parenthesized initializer (C++) or a function<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ;; prototype.<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (if (c-safe (c-forward-sexp 1) t)<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp; (c-forward-syntactic-ws limit)<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;(goto-char limit)))<br>
  <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (got-init<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ;; Skip an initializer expression.&nbsp; If we're at a '='<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ;; then accept a brace list directly after it to cope<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ;; with array initializers.&nbsp; Otherwise stop at braces<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ;; to avoid going past full function and class blocks.<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (and (if (and (eq got-init ?=)<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; (= (c-forward-token-2) 0)<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; (looking-at "{"))<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; (c-safe (c-forward-sexp) t)<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; t)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ;; BUG?&nbsp; The following line blows out because (not (&lt;
(point) limit)) !!<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; (c-syntactic-re-search-forward "[;,{]" limit 'move t)<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; (backward-char)))<br>
  <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (t (c-forward-syntactic-ws limit)))<br>
&nbsp; ...<br>
nil)<br>
</blockquote>
<br>
I've been using a workaround that merely replaces my "BUG" comment line
above with a (&lt; (point) limit) expression.&nbsp; I'll not claim that this
is the corrent fix, but it works for me (so far) without introducing
other obvious problems.<br>
<br>
Thanks,<br>
&nbsp;&nbsp;&nbsp; Michael Thome<br>
&nbsp;&nbsp;&nbsp; <a class="moz-txt-link-abbreviated" href="mailto:mt...@bb...">mt...@bb...</a><br>
<br>
PS bug-cc-mode doesn't appear on the gnu mailman list - not sure if
there are archives somewhere, so I understand this may be a redundant
report.<br>
</body>
</html>