bug#28418: 25.2; c++ angle bracket incorrect mismatch

[Alan Mackenzie]

Hello again, Craig.

On Mon, Sep 11, 2017 at 17:55:08 -0000, Alan Mackenzie wrote:
> In article <mailman.329.1505143569.14750.bug-gnu-emacs@gnu.org> you wrote:



> > The opening angle bracket from the stream insertion operator (<<)
> > becomes misclassified as an opening delimiter if a later string literal in 
> > the
> > file contains >>

> Firstly, thanks for taking the trouble to report this bug, and thanks
> even more for trimming it down to a nice, easy to work with snippet.

> > See the following sample file.  Notice that you must type in the string
> > as indicated because the act of typing triggers the misclassification.
> > When the error occurs, the closing bracket matches the '<' right before 
> > "nice". 

> Being more precise, I think the >> in the string already has to exist at
> the time the << gets typed.

> > I suggest pasting this into a new file and then manipulating the first 
> > string.


> > //---------------------------
> > int main(int argc, char *argv[])
> > {
> >   std::cout << "nice"; // <-- manually type in this string
> >   return 0;
> > }

> > void subroutine()
> > {
> >     char* foo= "a >> b";
> >     return;
> > }

> > //---------------------------

> What seems to be happening is after typing in the opening " of "nice",
> but before typing in the closing ", we have a sort of string extending
> from that opening " to the opening " of "a >> b".  That >> is
> (temporarily) outside a string, and is thus balanced with the <<.  This
> balancing is done by applying a "text property" to each of the second <
> and the first > characters.

> Where things go wrong is when "nice" is closed by typing the closing ".
> At this point, the text properties don't get removed from these < and >,
> although they no longer match.  This is the fault in the code.

> Give me a little time, and I will fix it.

More precisely, the error was allowing those two characters to be
matched in the first place.  This happened when trying to parse a < .. >
construct starting at the <<, which fails, since the << is not a
template delimiter.  The bug was then to move a single character
forward, then search for the next < (which is finds without moving).
Now it manages spuriously to parse the < .. >, and matches the < and the
>.  The solution is instead to move a whole token forward.

The following patch should fix this.  Please apply this to your Emacs
(cc-engine.el is in directory ..../emacs/lisp/progmodes) and recompile
cc-engine.el.  Please then check that the bug is fixed properly in your
real code, and let me know how it goes.

(If you want any help in applying the patch, or byte-compiling
cc-engine.el, feel free to contact me by private email.)

Here's the patch:


diff -r d0ed864dd852 cc-engine.el
--- a/cc-engine.el      Sun Sep 03 10:33:57 2017 +0000
+++ b/cc-engine.el      Mon Sep 11 21:02:25 2017 +0000
@@ -6431,7 +6431,7 @@
                              (not (eq (c-get-char-property (point) 'c-type)
                                       'c-decl-arg-start)))))))
       (or (c-forward-<>-arglist nil)
-         (forward-char)))))
+         (c-forward-token-2)))))
 
 
 ;; Functions to handle C++ raw strings.



> > ----
> > Craig Tanis, PhD
> > UTC Computer Science and Engineering
> > craig-tanis@utc.edu

-- 
Alan Mackenzie (Nuremberg, Germany).




> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot