bug#72695: CC Mode 5.35.2 (C++//l); c++-mode misindents 'if constexpr' inside lambdas

--===============2455442680476071319==
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello Alan,

Alan Mackenzie <[email protected]> writes:

> Hello, Arsen.
>
> Thanks for the bug report!

My pleasure.  Thanks for being as fast as always.

> On Sun, Aug 18, 2024 at 11:50:32 +0200, Arsen Arsenovi=C4=87 via CC-Mode-=
help wrote:
>> Package: cc-mode
>
>> <#secure method=3Dpgpmime mode=3Dsign>
>> Package: cc-mode
>> Hi!
>
>> CC-mode appears to misindent the following C++ snippet:
>
>>   void f()
>>   {
>>     auto data_printer =3D [] <typename T>
>>       (const T& data)
>>       {
>>         if constexpr (true)
>>         {
>>           if constexpr (std::same_as<T, std::string>)
>>           std::println (" data: \"{}\"", data);
>>           else
>>             std::println (" data: {}", data);
>>         }
>>         else
>>           std::println ("");
>>       };
>=20=20=20
>>     if constexpr (false)
>>       {
>>         foo ();
>>       }
>>   }
>
>> This example is supposed to be formatted in accordance to the default
>> GNU style, but the 'if constexpr' in the lambda expression are
>> misindented.
>
> Yes.
>
>> This might be the case because the inline-open of the lambda gets
>> mis-interpreted as statement-cont, so the statements in the body are
>> indented as brace-list-intro and brace-entry-open rather than
>> statement-block-intro and substatement-open.
>
> It's definitely something to do with the lambda function.  If I comment
> out Lines 3 and 4, the remainder of the function then indents correctly.
> As you remark, at the moment some lines are being wrongly analysed as
> brace-list constructs.
>
>> WRT lambda indentation generally, CC-mode appears to format lambdas in
>> GNU style so that their '{' aligns with their '[' (i.e. aligns their
>> compound-statement with their lambda-introducer per ISO parlance).
>> Maybe we should consider indenting them less. ....
>
> OK.  I'll fix the "brace-list" indentation bug first, then come back to
> this lambda indentation problem.

Thank you very much!

In the in-between time since I've sent this bug report with a feature
request snuck in, I've noticed the following in the GCC code:

  stattype =3D (cp_build_type_attribute_variant
	      (stattype, TYPE_ATTRIBUTES (optype)));

... which clued me into a different way to get the effect Lisp had, so I
figured out I can use the same trick for nested multi-line constructs:

    (std::visit
     ([] <typename T>
      (const T& data)
      {
        if constexpr (!std::same_as<T, std::monostate>)
          {
            if constexpr (std::same_as<T, std::string>)
              /* TODO(arsen): use {:?} here  */
              std::println (" data: \"{}\"", data);
            else
              std::println (" data: {}", data);
          }
        else
          std::println ("");
      }, tok.data));
  }

... which is an okay immitation of what Lisp does, and seems to provide
okay indentation here.  So maybe it's best not to avoid messing with
peoples styles ;) - please do not worry about the latter part of my
original message.

Thank you again!  Have a lovely evening.
=2D-=20
Arsen Arsenovi=C4=87

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZsZQol8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF
MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy
c2VuLm1lAAoJEFLClDAeosSTuGQBAJvPE1mRhhDVpM6IDkdOnsdjhuDqfDAxzfB6
sXpXvRCWAPwPXdzwsiw0CDvyVagPqTuIsmpFBitRUw5fTY/0H7b3CA==
=3GJj
-----END PGP SIGNATURE-----
--=-=-=--




--===============2455442680476071319==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============2455442680476071319==--