Re: cc-mode uniform initialization support

[Alan Mackenzie]

Hello, Daniel.

On Wed, Aug 19, 2015 at 11:36:11AM -0700, Daniel Colascione wrote:
> Recent versions of C++ support using {} to indicate an initialization
> value. For example,

>   1 int foo{5};
>   2 int bar = {5};
>   3 mumble_t mumble{
>   4  foo,
>   5    bar
>   6 };
>   7 return {mumble, foo}; // Type inferred from function declaration

Yes.

> Working with code written in this style is a nightmare right now because
> cc-mode recognizes line 4 as defun-block-intro, leading to line 5 being
> indented spuriously, since cc-mode thinks it's a statement continuation.
> In reality, the construct starting at line 3 is a brace list, but
> there's no syntactic clue to tell us that.

How about the fact that there's no argument list (in parens)?  Is that
not sufficient to distinguish a brace list from a defun?

> (We can, of course, look for an "=", but an "=" is no longer required
> for a brace list.)

> I don't see a way around needing to use awful heuristics to distinguish
> the cases. Does anyone have a better idea? Keep in mind that code like
> this is common too:

>   foo({
>     abc,
>     def
>   });

> And plenty of people define macros that accept blocks:

>   MY_FOREACH {
>     statement1;
>     statement2;
>   }

I've had a look at your patch, and after correcting it (so that at the
indicated lines, the result of the `looking-at' is returned rather than
the result of `backward-char' (which is nil)), tried it out.  It does
indeed appear to work on the example code you gave.

However, it gives lots of errors in the test suite, including in some
C++ test files (namely decls-15.cc, inexprstat-2.cc, inher-9.cc), so it
needs some refinement.  There are also a few niggly details where the
patch isn't quite correct, but they should be easy enough to correct.

Why do you distinguish between "\\w{" and "\\w {" in the `looking-at'
form?

> diff --git a/lisp/progmodes/cc-engine.el b/lisp/progmodes/cc-engine.el
> index 06b03a2..84f3ad7 100644
> --- a/lisp/progmodes/cc-engine.el
> +++ b/lisp/progmodes/cc-engine.el
> @@ -8725,6 +8725,34 @@ comment at the start of cc-engine.el for more info."
>     (save-excursion
>       (goto-char containing-sexp)
>       (c-backward-over-enum-header))
> +   ;; Detect C++11 uniform initialization.  This bit is necessarily
> +   ;; heuristic, since there are few syntactic clues to go
> +   ;; on. Initializer lists can now stand in for any value at all when
> +   ;; the compiler can infer the type to build from the
> +   ;; initializer list.
> +   (save-excursion
> +     (goto-char containing-sexp)
> +     (and
> +      (eq (char-after) ?\{)
> +      (progn (c-backward-sws)
> +            (or
> +             ;; After a comma means universal initialization
> +             (eq (char-before) ?\,)
> +             ;; Er, we use GCC statement expressions most often in
> +             ;; macros, so if we see ({ outside of one, think of it
> +             ;; as uniform initialization.
> +             (and (eq (char-before) ?\()
> +                  (save-excursion
> +                    (not (c-beginning-of-macro))))
> +             ;; foo{} versus foo {. Yuck.
> +             (and (not (bobp))
> +                  (prog1                       <===================
> +                      (backward-char)          <===================
> +                    (looking-at "\\(\\w\\|\\s_\\){")
> +                    (forward-char)))
> +             ;; Special case for return {...}
> +             (looking-back "\\_<return\\=" (point-at-bol))))
> +      containing-sexp))
>     ;; this will pick up array/aggregate init lists, even if they are nested.
>     (save-excursion
>       (let ((class-key

-- 
Alan Mackenzie (Nuremberg, Germany).