bug#10941: [24.0.93.3] cc-mode: error in message buffer when "typing fast", characters eaten

bug#10941: [24.0.93.3] cc-mode: error in message buffer when "typing fast", characters eaten

[Paul Pogonyshev]

[-- Attachment #1: Type: Text/Plain, Size: 918 bytes --]

Sometimes (quite often) when opening a different syntax region --- a
quoted string, or block comment --- in C++ mode, the first character
after it gets eaten with some error message shown in the echo area.  I
managed to create a surefire (at least here) way to reproduce it.

* save the attached file as 'test.cpp' (it is quite large, but when I
  tried to shorten it substantially, error disappeared);

* start Emacs as 'emacs -Q test.cpp';

* issue Elisp command right at the start of the buffer with M-: (this
  emulates fast typing):

      (progn (insert "/*") (insert " "))

  note that two separate inserts are essential, with one "/* " error
  is not triggered;

* observer the following error:

      Debugger entered--Lisp error: (error "Invalid search bound
      (wrong side of point)")

Full Emacs version: GNU Emacs 24.0.93.3 (x86_64-unknown-linux-gnu,
GTK+ Version 2.24.10) of 2012-02-25 on gonzo

Paul

[-- Attachment #2: test.cpp --]
[-- Type: text/x-c++src, Size: 3990 bytes --]

namespace mct
{

  // Templated structure specifying how given type could be used by its container (in
  // broad sense), i.e. "externally".  Default is no external use; it can be enabled by
  // specializing the structure.
  template <typename Type, typename = void>
  struct external_use
  { };


  template <typename Type, typename = Type>
  struct supports_external_use : impl::false_type
  { };

  template <typename Type>
  struct supports_external_use <Type, typename external_use <Type>::type> : impl::true_type
  { };


  template <typename Type, typename Value, Value Type::* field,
            bool direct_access = (impl::is_integral <Value>::value
                                  && !impl::is_same <Value, bool>::value),
            bool recurse       = supports_external_use <Value>::value>
  struct extern_use_field;

  template <typename Type, typename Value, Value Type::* field>
  struct extern_use_field <Type, Value, field, true, false>
  {
    typedef  Type   type;
    typedef  Value  value_type;

    static  const value_type&
    get (const type& structure)
    {  return structure.*field;  }

    static  void
    set (type& structure, const value_type& value)
    {  structure.*field = value;  }
  };

  template <typename Type, typename Value, Value Type::* field>
  struct extern_use_field <Type, Value, field, false, true>
  {
    typedef  Type                                       type;
    typedef  typename external_use <Value>::value_type  value_type;

    static  const value_type&
    get (const type& structure)
    {
      return external_use <Value>::get (structure.*field);
    }

    static  void
    set (type& structure, const value_type& value)
    {
      external_use <Value>::set (structure.*field, value);
    }
  };


  template <typename First, typename Second>
  struct external_use <std::pair <First, Second>,
                       typename impl::enable_if <supports_external_use <First>::value>::type>
    : extern_use_field <std::pair <First, Second>, First, &std::pair <First, Second>::first>
  { };

  template <typename First, typename Second>
  struct external_use <std::pair <First, Second>,
                       typename impl::enable_if <supports_external_use <Second>::value
                                                 && !supports_external_use <First>::value>::type>
    : extern_use_field <std::pair <First, Second>, Second, &std::pair <First, Second>::second>
  { };


  namespace impl
  {

    // By default the structure is empty.  'intrusive_storage' below makes sure to never
    // use it when it's empty, i.e. of size 1.
    template <typename type, typename = void>
    struct extern_use_wrapper
    { };


# if 0

    // Ideally we'd want this, but see comment in the preprocessor-enabled branch.
    template <typename type>
    struct extern_use_wrapper <type, typename impl::enable_if <std::is_class <type>::value>::type>
      : type
    // ...

# else

    // We currently specialize 'extern_use_wrapper' very conservatively.  At least GCC up
    // to 4.6 doesn't provide 'std::is_class', so there is no reliable way to determine if
    // 'type' is subclassable without requiring a recent compiler.  The most important
    // case, especially for maps, is 'std::pair', so we limit ourselves to that for now.
    template <typename First, typename Second>
    struct extern_use_wrapper <std::pair <First, Second> > : std::pair <First, Second>
    {
      typedef  std::pair <First, Second>  base_type;

      char  _unused;

      extern_use_wrapper&
      operator= (const extern_use_wrapper& that)
      {
        return static_cast <extern_use_wrapper&> (base_type::operator= (that));
      }

#   if MCT_CXX0X_SUPPORTED

      extern_use_wrapper&
      operator= (extern_use_wrapper&& that)
      {
        return static_cast <extern_use_wrapper&> (base_type::operator=
                                                  (std::forward <base_type> (that)));
      }

#   endif
    };

# endif

  }

}

bug#10941: [24.0.93.3] cc-mode: error in message buffer when "typing fast", characters eaten

[Alan Mackenzie]

Hi, Paul.

Thanks for this report.  I can reproduce the error.  However, looking at
the code, it "can't possibly happen".  :-(  A few questions:

> Sometimes (quite often) when opening a different syntax region --- a
> quoted string, or block comment --- in C++ mode, the first character
> after it gets eaten with some error message shown in the echo area.  I
> managed to create a surefire (at least here) way to reproduce it.

What exactly do you mean by "opening a different syntax region"?  Do you
mean moving point into it, or scrolling to see it?

> * save the attached file as 'test.cpp' (it is quite large, but when I
>   tried to shorten it substantially, error disappeared);

Aha!  It's 3991 bytes long.  I'm going to try a binary chop on the
length.  I have a strange feeling the threshold length of the file
(before insertion of "/* ") will be 2048.

> * start Emacs as 'emacs -Q test.cpp';

> * issue Elisp command right at the start of the buffer with M-: (this
>   emulates fast typing):

>       (progn (insert "/*") (insert " "))

>   note that two separate inserts are essential, with one "/* " error
>   is not triggered;

OK.  I have a suspicion it could be something like two
before-change-functions being invoked without the after-change-function
which should come between them.

Strangely, though, once this error has happened, it doesn't happen again
in the same Emacs session, even if the buffer is killed and the file
reloaded.

> * observer the following error:

>       Debugger entered--Lisp error: (error "Invalid search bound
>       (wrong side of point)")

> Full Emacs version: GNU Emacs 24.0.93.3 (x86_64-unknown-linux-gnu,
> GTK+ Version 2.24.10) of 2012-02-25 on gonzo

Paul

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#10941: [24.0.93.3] cc-mode: error in message buffer when "typing fast", characters eaten

[Paul Pogonyshev]

Alan Mackenzie wrote:
> > Sometimes (quite often) when opening a different syntax region --- a
> > quoted string, or block comment --- in C++ mode, the first character
> > after it gets eaten with some error message shown in the echo area.  I
> > managed to create a surefire (at least here) way to reproduce it.
> 
> What exactly do you mean by "opening a different syntax region"?  Do you
> mean moving point into it, or scrolling to see it?

Just typing, similarly to the testcase.  When you quickly type an
opening quote (") or inline comment starter (/*) and then instantly
continue typing whatever is going to be inside, this error happens.
Far from always, but often enough to be annoying.

> OK.  I have a suspicion it could be something like two
> before-change-functions being invoked without the after-change-function
> which should come between them.

I have a different suspicion that sometimes cc-mode relies on data
found in font-lock only and that data may or may not be present (or up
to date) depending on how fast lazy font-locking happens.  But of
course you know the code better to decide if that is possible at all.

Paul

bug#10941: [24.0.93.3] cc-mode: error in message buffer when "typing fast", characters eaten

[Alan Mackenzie]

Hello, Paul.

On Fri, Mar 30, 2012 at 01:11:05AM +0300, Paul Pogonyshev wrote:
> Alan Mackenzie wrote:
> > > Sometimes (quite often) when opening a different syntax region --- a
> > > quoted string, or block comment --- in C++ mode, the first character
> > > after it gets eaten with some error message shown in the echo area.  I
> > > managed to create a surefire (at least here) way to reproduce it.

> > What exactly do you mean by "opening a different syntax region"?  Do you
> > mean moving point into it, or scrolling to see it?

> Just typing, similarly to the testcase.  When you quickly type an
> opening quote (") or inline comment starter (/*) and then instantly
> continue typing whatever is going to be inside, this error happens.
> Far from always, but often enough to be annoying.

Thanks for the description.

I think I've found the trouble.  It was a simple mistake in calculating a
search limit.  I don't understand how this only bites when the buffer is
newly loaded, but whatever.

Would you please try out this patch and let me know whether it solves the
problem.


diff -r 002a49d7b836 cc-engine.el
--- a/cc-engine.el	Fri Mar 16 13:14:22 2012 +0000
+++ b/cc-engine.el	Fri Mar 30 22:13:40 2012 +0000
@@ -5414,7 +5414,7 @@
 	  new-beg new-end need-new-beg need-new-end)
       ;; Locate the barrier before the changed region
       (goto-char  (if beg-lit-limits (car beg-lit-limits) beg))
-      (c-syntactic-skip-backward "^;{}" (max (- beg 2048) (point-min)))
+      (c-syntactic-skip-backward "^;{}" (c-determine-limit 512))
       (setq new-beg (point))
 
       ;; Remove the syntax-table/category properties from each pertinent <...>
@@ -5426,8 +5426,7 @@
 
       ;; Locate the barrier after END.
       (goto-char (if end-lit-limits (cdr end-lit-limits) end))
-      (c-syntactic-re-search-forward "[;{}]"
-				     (min (+ end 2048) (point-max)) 'end)
+      (c-syntactic-re-search-forward "[;{}]" (c-determine-+ve-limit 512) 'end)
       (setq new-end (point))
 
       ;; Remove syntax-table properties from the remaining pertinent <...>

> Paul

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#10941: [24.0.93.3] cc-mode: error in message buffer when "typing fast", characters eaten

[Paul Pogonyshev]

Alan Mackenzie wrote:
> Would you please try out this patch and let me know whether it solves the
> problem.

Sorry, I can't because that'd require a lot of coding (the bug is not
deterministic) to see if the problem is gone and I don't code
currently.  Just commit it and close the bug as long as it solves the
original testcase.

Paul

bug#10941: [24.0.93.3] cc-mode: error in message buffer when "typing fast", characters eaten

[Alan Mackenzie]

(At least partially) fixed.

-- 
Alan Mackenzie (Nuremberg, Germany).