bug#19867: c++-mode indentation issues with C++1x initializer lists

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Simon]

[-- Attachment #1: Type: text/plain, Size: 4142 bytes --]

Package: emacs
Version: 24.4.1
Severity: important

Related: c++-mode


Initializer lists use curly braces, but their contents do not indent
properly with emacs' c++-mode.
In short, one may use an initializer list to declare and initialize a
vector of integers as such:
  std::vector<int> Foo( { 1, 2, 3, 4, 5 } );

Problems arise when the elements of the list span on multiple line and it
gets even worse when the elements are lambda-expressions and nested
initializer lists.
The following code illustrate most cases and related situations.  The code
below compiles without error or warning with gcc 4.8.3.


In case email systems mess with the spaces, the code below is available at
this URL as well:
http://next.n32.ca/emacs_initlist_indentation_bug.txt

#include <vector>
#include <functional>

namespace emacs_initlist_indentation_bug {

  struct ABC {
    int a;  // OK, text-book indentation
    int b;  //
    int c;  //
  };

  struct DEF {
    int d, //
      e,   // indented from "int" + 2
      f;   //
  };

  struct GHI {
    int   //
    g,    // indented from "int" +0
      h,  // indented from "int" + 2
      i;  //
  };

  int f1 ( int a,  // Indentation OK in function declaration context
	   int b,  //
	   int c   //
	   )       // Notice how the ")" is indented
  {

    if(a>0){

      return a+  // while out-of-topic, this probably pinpoints
	b+       // what's going on internally
	c;       //

    } else if(a<0) {

      return (a+  // these are well aligned
	      b+  //
	      c); //

    } else {

      return
	(a+  // these are well aligned
	 b+  //
	 c); //

    }
  }

  void f2 (const ABC& abc)
  {
    f1(abc.a,  // Indentation OK in function call context
       abc.b,  //
       abc.c); //
  }

  void f3 (int a, int b, int c)
  {
    f1( f1( a+1,    // Indentation OK, text-book example, perfect!
	    b+1,    //
	    c+1 ),  //
	f1( a+2,    //
	    b+2,    //
	    c+2 ),  //
	f1( a+3,    //
	    b+3,    //
	    c+3 )   //
	);          //
  }

  void f4 (int a, int b, int c)
  {
    f2({a+1,     // note "{" on same line as "("
	  b+1,   // indented after "{" + 2
	  c+1}   //
      );         // Bad! ")" indented underneath "(" instead of
argument (ie. "{")

    f2(
       {a+2,     // note "{" on different line as "("
	   b+2,  // indented after "{" + 3 !!!
	   c+2}  //
       );        // OK, ")" indented underneath "{"

    // Below are some typical indentation I'm getting these days.
    // The only difference is in the newline on first line (and numerics)

    std::vector<ABC> abcList1({{a+1, //
	    b+1,                     //
	    c+1},                    //
	  {a+2,                      //
	      b+2,                   //
	      c+2},                  //
	    {a+3,                    //
		b+3,                 //
		c+3}                 //
      }                              //
      );                             //

    std::vector<ABC> abcList2(                     // Source of
alignment for closing ")" below
			      {{a+4,               //
				    b+4,           //
				    c+4},          //
				  {a+5,            //
				      b+5,         //
				      c+5},        //
				    {a+6,          //
					b+6,       //
					c+6}       //
			      }                    //
						   ); /* Somehow, this one aligns with first line's comment position!! */

  }


  void f5 ()
  {
    int foo = 0;
    std::vector< std::function<int(int)> >
      lambda_initlist_bug({    //
	  [foo](int x)         //
	    {                  // BAD, too indented by 2 positions
	      return x+x;      //
	    },                 //
	    [foo](int y)       //
	      {                // BAD, too indented by 2 positions
		return y+y;    //
	      },               //
	      [foo](int z)     //
		{              // BAD, too indented by 2 positions
		  return z+z;  //
		}              //
	}
	);

    lambda_initlist_bug.push_back(              //
				  [](int p)     // OK, text-book indentation
				  {             //
				    return p+p; //
				  }             //
						);  /* Aligned with first comment! */

    for(auto f_lambda : lambda_initlist_bug){
      f_lambda( 123 );
    }

  }

}

[-- Attachment #2: Type: text/html, Size: 5036 bytes --]

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Glenn Morris]

Simon wrote:

> Severity: important

Unless it leads to invalid code (eg Python-style languages), I tend to
think of indentation bugs as minor problems, since it's just cosmetic.
Why do you think this one is important?

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Simon]

On Mon, Feb 16, 2015 at 2:09 PM, Glenn Morris <rgm@gnu.org> wrote:
> Simon wrote:
>
>> Severity: important
>
> Unless it leads to invalid code (eg Python-style languages), I tend to
> think of indentation bugs as minor problems, since it's just cosmetic.
> Why do you think this one is important?

I am inclined to follow your lead.  C++ code compiles without errors
as I mentioned.

The bug affects "c++-mode" and since c++-mode mostly (solely?) affects
cosmetics, then the bug makes c++-mode difficult to use.  In fact, I
have been searching for alternatives, in vain.

I would suggest keeping severity as "important" if this report can be
assigned more precisely to the "c++-mode" sub-package or group.  If
not, then you may downgrade to "minor" as you said.

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

On 02/16/2015 11:09 AM, Glenn Morris wrote:
> Simon wrote:
> 
>> Severity: important
> 
> Unless it leads to invalid code (eg Python-style languages), I tend to
> think of indentation bugs as minor problems, since it's just cosmetic.
> Why do you think this one is important?

Indentation bugs are infuriating because I use electric mode, which
means that even if I fix the indentation, the fixes are undone
automatically.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

On 02/16/2015 11:29 AM, Simon wrote:
> On Mon, Feb 16, 2015 at 2:09 PM, Glenn Morris <rgm@gnu.org> wrote:
>> Simon wrote:
>>
>>> Severity: important
>>
>> Unless it leads to invalid code (eg Python-style languages), I tend to
>> think of indentation bugs as minor problems, since it's just cosmetic.
>> Why do you think this one is important?
> 
> I am inclined to follow your lead.  C++ code compiles without errors
> as I mentioned.
> 
> The bug affects "c++-mode" and since c++-mode mostly (solely?) affects
> cosmetics, then the bug makes c++-mode difficult to use.  In fact, I
> have been searching for alternatives, in vain.
> 
> I would suggest keeping severity as "important" if this report can be
> assigned more precisely to the "c++-mode" sub-package or group.  If
> not, then you may downgrade to "minor" as you said.

OP, your best bet is to dive into cc-engine.el and fix it yourself.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Glenn Morris]

In Emacs, we traditionally reserve severity > normal for failure to
build, security issues etc. So I'll downgrade this to normal, but don't
worry, because I have seen very little evidence that the severity makes
any difference to whether something gets fixed. :), and :( too.

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Simon]

> In Emacs, we traditionally reserve severity > normal for failure to
> build, security issues etc. So I'll downgrade this to normal, but don't
> worry, because I have seen very little evidence that the severity makes
> any difference to whether something gets fixed. :), and :( too.

Sounds good.  Thank you Glenn.

I hope someone can look into this within a year or two.  Ideally,
before C++17 becomes a reality and swizzles the syntax further with
its "concepts lite" and other features.

I also noticed some more strange indentation cases with nested
constructor initialization lists.  I'll be available to test any
improvements made and provide more test cases if needed.  Thanks
again.

bug#19867: c++-mode indentation issues with C++1x initializer lists

[Stefan Kangas]

Simon <turner25@gmail.com> writes:

> Initializer lists use curly braces, but their contents do not indent properly with emacs' c++-mode.
> In short, one may use an initializer list to declare and initialize a vector of integers as such:
>   std::vector<int> Foo( { 1, 2, 3, 4, 5 } );
>
> Problems arise when the elements of the list span on multiple line and it gets even worse when the elements are lambda-expressions
> and nested initializer lists.
> The following code illustrate most cases and related situations.  The code below compiles without error or warning with gcc 4.8.3.

I had a look at the fairly long example provided here, and AFAICT, the
indentation is incorrect in the below cases (trimmed down from the
original).  Some of the examples of incorrect indentation were already
fixed.

Alan, could you perhaps take a look at this and see if this is something
that is fixable?  Thanks in advance.


#include <vector>
#include <functional>

namespace emacs_initlist_indentation_bug {
  struct DEF {
    int d, //
      e,   // indented from "int" + 2
      f;   //
  };
  struct GHI {
    int   //
    g,    // indented from "int" +0
      h,  // indented from "int" + 2
      i;  //
  };

  void f4 (int a, int b, int c)
  {
    std::vector<ABC> abcList2(                     // Source of
alignment for closing ")" below
      {{a+6,
        b+6,
        c+6}
      }                    //
                                                   ); /* Somehow, this
one aligns with first line's comment position!! */
  }

  lambda_initlist_bug.push_back(              //
    [](int p)     // OK, text-book indentation
    {             //
      return p+p; //
    }             //
                                              );  /* Aligned with
first comment! */
  }
}