GNU bug report logs -
#19867
c++-mode indentation issues with C++1x initializer lists
Previous Next
Reported by: turner25 <at> gmail.com
Date: Sat, 14 Feb 2015 18:17:01 UTC
Severity: minor
Found in version 24.4.1
Done: Alan Mackenzie <acm <at> muc.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Thu, 27 Mar 2025 10:42:35 +0000
with message-id <Z-Urm6rXUPBkapMZ <at> MAC.fritz.box>
and subject line Re: bug#19867: c++-mode indentation issues with C++1x initializer lists
has caused the debbugs.gnu.org bug report #19867,
regarding c++-mode indentation issues with C++1x initializer lists
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
19867: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19867
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
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 );
}
}
}
[Message part 4 (text/html, inline)]
[Message part 5 (message/rfc822, inline)]
Hello, Stefan.
On Tue, Mar 11, 2025 at 16:23:13 -0400, Stefan Kangas wrote:
> Alan Mackenzie <acm <at> muc.de> writes:
> > Yes, I'll do this. Sorry I never replied to your post in 2020. I
> > started looking at the bug then, but somehow didn't get very far with it.
> > Maybe it was because there were so many individual glitches in the
> > report. Thanks for distilling the cases which still remain unfixed.
> Thanks!
I've just committed a fix (a ~700 line patch ;-), so I think this bug is
finally solved.
I'm closing the bug with this post.
--
Alan Mackenzie (Nuremberg, Germany).
This bug report was last modified 3 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.