From: Alan Mackenzie <acm@muc.de>
To: Michael Welsh Duggan <mwd@cert.org>
Cc: "11749@debbugs.gnu.org" <11749@debbugs.gnu.org>,
Kim Storm <storm@cua.dk>
Subject: bug#11749: Acknowledgement (24.1; C-mode indentation gives wrong-type-argument error.)
Date: Sun, 14 Oct 2012 17:06:50 +0000 [thread overview]
Message-ID: <20121014170650.GA3766@acm.acm> (raw)
In-Reply-To: <20121010200025.GA3449@acm.acm>
Hi, Michael,
On Wed, Oct 10, 2012 at 08:00:25PM +0000, Alan Mackenzie wrote:
> On Tue, Oct 09, 2012 at 10:05:07AM -0400, Michael Welsh Duggan wrote:
> > Alan Mackenzie <acm@muc.de> writes:
[ .... ]
> > > I have found the bug which is causing (most of) these dings, though I
> > > don't think it is the one which caused Kim's original bug. Could you try
> > > out the patch below, please. (I have also enhanced/corrected the
> > > debugging routines a bit, too.)
> > Still doesn't seem to help much here. I have attached a file which
> > reliably causes a cache failure. I have attached the smallest file of
> > the set of files I am working on that causes this particular problem.
> > Load the attached file and toggle on parse state debugging. Then scroll
> > to the bottom of the file. (Use C-v multiple times, or just M->.) One
> > reason I have attached this file is that it only triggers the warning
> > message once. Most of my larger files cause this to happen quite a lot.
> What is happening in this file is another bug, arising from historical
> assumptions which are no longer valid.
> The "from scratch" calculation notes that the starting scanning position
> would be a long way (>5000) back, hence it tries going back to the second
> "beginning-of-defun" to get a top-level starting point. This
> "beginning-of-defun" is a pure "brace in column zero" test.
> This doesn't work in C++ when constructs inside a namespace have braces
> at column zero, something I believe has become very common in recent
> years. Namespaces didn't exist in C++ when c-parse-state was originally
> written.
> Obviously this optimisation is no longer valid. I wouldn't be surprised
> if it has caused quite a bit of buggy behaviour. I'll need to think it
> over for a few days to decide what to do.
The only reasonable thing to do is to disable the heuristic for C++ Mode.
This is what the patch below now does. Could you try it out as usual,
please. Thanks!
diff -r ac6584d14c06 cc-engine.el
--- a/cc-engine.el Sun Sep 09 11:15:13 2012 +0000
+++ b/cc-engine.el Sun Oct 14 17:02:08 2012 +0000
@@ -2560,8 +2560,11 @@
start-point cache-pos)))
;; Might we be better off starting from the top level, two defuns back,
- ;; instead?
- (when (> how-far c-state-cache-too-far)
+ ;; instead? This heuristic no longer works well in C++, where
+ ;; declarations inside namespace brace blocks are frequently placed at
+ ;; column zero.
+ (when (and (not (c-major-mode-is 'c++-mode))
+ (> how-far c-state-cache-too-far))
(setq BOD-pos (c-get-fallback-scan-pos here)) ; somewhat EXPENSIVE!!!
(if (< (- here BOD-pos) how-far)
(setq strategy 'BOD
@@ -2648,17 +2651,19 @@
;; If we're essentially repeating a fruitless search, just give up.
(unless (and c-state-brace-pair-desert
(eq cache-pos (car c-state-brace-pair-desert))
+ (> from (car c-state-brace-pair-desert))
(<= from (cdr c-state-brace-pair-desert)))
- ;; DESERT-LIM. Only search what we absolutely need to,
+ ;; DESERT-LIM. Avoid repeated searching through the cached desert.
(let ((desert-lim
(and c-state-brace-pair-desert
(eq cache-pos (car c-state-brace-pair-desert))
+ (>= from (cdr c-state-brace-pair-desert))
(cdr c-state-brace-pair-desert)))
;; CACHE-LIM. This limit will be necessary when an opening
;; paren at `cache-pos' has just had its matching close paren
- ;; inserted. `cache-pos' continues to be a search bound, even
- ;; though the algorithm below would skip over the new paren
- ;; pair.
+ ;; inserted into the buffer. `cache-pos' continues to be a
+ ;; search bound, even though the algorithm below would skip
+ ;; over the new paren pair.
(cache-lim (and cache-pos (< cache-pos from) cache-pos)))
(narrow-to-region
(cond
@@ -3354,13 +3359,19 @@
(fset 'c-real-parse-state (symbol-function 'c-parse-state)))
(cc-bytecomp-defun c-real-parse-state)
+(defvar c-parse-state-point nil)
(defvar c-parse-state-state nil)
(make-variable-buffer-local 'c-parse-state-state)
(defun c-record-parse-state-state ()
+ (setq c-parse-state-point (point))
(setq c-parse-state-state
(mapcar
(lambda (arg)
- (cons arg (symbol-value arg)))
+ (let ((val (symbol-value arg)))
+ (cons arg
+ (if (consp val)
+ (copy-tree val)
+ val))))
'(c-state-cache
c-state-cache-good-pos
c-state-nonlit-pos-cache
@@ -3373,7 +3384,8 @@
c-state-point-min-lit-start
c-state-min-scan-pos
c-state-old-cpp-beg
- c-state-old-cpp-end))))
+ c-state-old-cpp-end
+ c-parse-state-point))))
(defun c-replay-parse-state-state ()
(message
(concat "(setq "
@@ -3416,7 +3428,8 @@
(message "Old state:")
(c-replay-parse-state-state))
(c-record-parse-state-state)
- res1))
+ res2 ; res1 correct a cascading series of errors ASAP
+ ))
(defun c-toggle-parse-state-debug (&optional arg)
(interactive "P")
> > --
> > Michael Welsh Duggan
> > (mwd@cert.org)
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2012-10-14 17:06 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-19 20:45 bug#11749: 24.1; C-mode indentation gives wrong-type-argument error Kim F. Storm
2012-06-21 7:17 ` Glenn Morris
2012-06-21 9:34 ` Kim Storm
2012-08-28 16:17 ` bug#11749: 24.2; wrong-type-argument Kim F. Storm
[not found] ` <handler.11749.B.13401389485673.ack@debbugs.gnu.org>
2012-08-28 22:49 ` bug#11749: Acknowledgement (24.1; C-mode indentation gives wrong-type-argument error.) Kim Storm
2012-08-31 11:01 ` Eli Zaretskii
2012-08-31 12:37 ` Kim Storm
2012-09-02 21:16 ` Alan Mackenzie
2012-09-03 9:47 ` Kim Storm
2012-09-03 13:56 ` Stefan Monnier
2012-09-03 14:20 ` Kim Storm
2012-09-03 18:52 ` Stefan Monnier
2012-09-05 20:48 ` Alan Mackenzie
2012-09-07 3:45 ` Michael Welsh Duggan
2012-09-07 14:53 ` Stefan Monnier
2012-09-07 16:16 ` Kim Storm
2012-09-08 21:14 ` Alan Mackenzie
2012-09-10 12:18 ` Michael Welsh Duggan
2012-09-10 12:48 ` Michael Welsh Duggan
2012-09-21 17:47 ` Michael Welsh Duggan
2012-10-07 10:59 ` Alan Mackenzie
2012-10-09 14:05 ` Michael Welsh Duggan
2012-10-10 20:00 ` Alan Mackenzie
2012-10-14 17:06 ` Alan Mackenzie [this message]
2012-10-23 16:13 ` Michael Welsh Duggan
2012-10-25 13:41 ` Michael Welsh Duggan
2012-10-28 11:36 ` Alan Mackenzie
2012-11-04 3:43 ` Chong Yidong
2012-11-04 20:42 ` Alan Mackenzie
2012-11-21 20:58 ` Alan Mackenzie
2012-11-22 14:52 ` Stefan Monnier
2012-11-04 20:39 ` Alan Mackenzie
2012-11-04 21:04 ` Kim Storm
2012-11-14 16:52 ` Michael Welsh Duggan
2012-11-21 21:33 ` Alan Mackenzie
2012-11-26 13:25 ` Michael Welsh Duggan
2012-12-10 3:35 ` Michael Welsh Duggan
2013-01-07 12:09 ` Alan Mackenzie
2013-01-17 16:27 ` Michael Welsh Duggan
2013-01-17 16:28 ` Michael Welsh Duggan
2013-01-23 14:16 ` Alan Mackenzie
2013-01-23 15:39 ` Michael Welsh Duggan
2013-01-29 11:37 ` Alan Mackenzie
[not found] ` <20130129113737.GA4544@acm.acm>
2013-02-01 22:18 ` Michael Welsh Duggan
2013-02-01 23:50 ` Kim Storm
2013-02-02 19:35 ` Alan Mackenzie
2012-09-10 13:10 ` Michael Welsh Duggan
2012-09-10 13:22 ` Michael Welsh Duggan
2012-09-10 18:25 ` Michael Welsh Duggan
2012-09-05 13:11 ` bug#11749: I also have this issue Denis Zalevskiy
2013-01-08 19:10 ` bug#11749: Acknowledgement (24.1; C-mode indentation gives wrong-type-argument error.) Glenn Morris
2013-01-09 22:13 ` Alan Mackenzie
2013-02-02 18:37 ` bug#11749: 24.1; C-mode indentation gives wrong-type-argument error Alan Mackenzie
2013-01-08 13:49 ` bug#13385: 24.1; TAB in C file causes type error Julian Stecklina
[not found] ` <handler.13385.D11749.1359830688892.notifdone@debbugs.gnu.org>
2013-02-03 13:00 ` bug#13385: closed (Re: 24.1; C-mode indentation gives wrong-type-argument error.) Julian Stecklina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121014170650.GA3766@acm.acm \
--to=acm@muc.de \
--cc=11749@debbugs.gnu.org \
--cc=mwd@cert.org \
--cc=storm@cua.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).