bug#24195: 25.0.95; Wrong indentation after a 'less < than' comparison (c++-mode)

bug#24195: 25.0.95; Wrong indentation after a 'less < than' comparison (c++-mode)

[Arash]

$ emacs -Q test.cc

bool test()
{
    return \
        a() <= b() &&
        c() >= d() &&
        e() == f() &&
        g() != h() &&
        i() >  j() &&
        k() <  l() &&
               m() == n() // !!!
        ;
}

bug#24195: 25.0.95; Wrong indentation after a 'less < than' comparison (c++-mode)

[Robert Cochran]

I can comfirm; error is still present on emacs-25 branch @ commit f785ff4
-- 
~Robert Cochran

GPG Fingerprint - E778 2DD4 FEA6 6A68 6F26  AD2D E5C3 EB36 4886 8871

bug#24195: 25.0.95; Wrong indentation after a 'less < than' comparison (c++-mode)

[Alan Mackenzie]

Hello, Arash.

On Wed, Aug 10, 2016 at 02:08:52PM +0430, Arash wrote:
> $ emacs -Q test.cc

> bool test()
> {
>     return \
>         a() <= b() &&
>         c() >= d() &&
>         e() == f() &&
>         g() != h() &&
>         i() >  j() &&
>         k() <  l() &&
              ^
>                m() == n() // !!!
>         ;
> }

Yes.  In the line "k() < l() &&", the "<" is being recognised as a
template opener.

The syntax of C++ is ambiguous, and it is difficult for anything which
isn't a compiler reliably to distinguish between "less than" and "open
template" in circumstances like that.  It was easier for earlier
versions of C++, where the "&&" operator wasn't valid inside a template.

I'm not sure I can do very much to help, here.  Even waiting on the
closing ">" before recognising a template wouldn't help much, because
you're just as likely to have the line with "<" before the line with
">".

There are crude workarounds, like writing "!(k() >= l()), but that's
horrible.

So, sorry and all that, I don't think I can do anything to fix this.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#24195: 25.0.95; Wrong indentation after a 'less < than' comparison (c++-mode)

[Noam Postavsky]

On Thu, Aug 11, 2016 at 8:14 AM, Alan Mackenzie <acm@muc.de> wrote:
> Yes.  In the line "k() < l() &&", the "<" is being recognised as a
> template opener.

Is it possible to say that "<" can't be a template opener when it
comes after a close paren? (I can't think of a case in C++ where that
would fail, though I'm not 100% certain there isn't one)

bug#24195: 25.0.95; Wrong indentation after a 'less < than' comparison (c++-mode)

[Andreas Schwab]

On Aug 12 2016, Noam Postavsky <npostavs@users.sourceforge.net> wrote:

> On Thu, Aug 11, 2016 at 8:14 AM, Alan Mackenzie <acm@muc.de> wrote:
>> Yes.  In the line "k() < l() &&", the "<" is being recognised as a
>> template opener.
>
> Is it possible to say that "<" can't be a template opener when it
> comes after a close paren? (I can't think of a case in C++ where that
> would fail, though I'm not 100% certain there isn't one)

operator()<foo>

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#24195: 25.0.95; Wrong indentation after a 'less < than' comparison (c++-mode)

[npostavs]

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Aug 12 2016, Noam Postavsky <npostavs@users.sourceforge.net> wrote:
>
>> On Thu, Aug 11, 2016 at 8:14 AM, Alan Mackenzie <acm@muc.de> wrote:
>>> Yes.  In the line "k() < l() &&", the "<" is being recognised as a
>>> template opener.
>>
>> Is it possible to say that "<" can't be a template opener when it
>> comes after a close paren? (I can't think of a case in C++ where that
>> would fail, though I'm not 100% certain there isn't one)
>
> operator()<foo>

So could we say "<" can't be a template opener when it comes after a
close paren except for the close paren of "operator()"?

bug#24195: 25.0.95; Wrong indentation after a 'less < than' comparison (c++-mode)

[Alan Mackenzie]

Hello, Noam.

On Thu, Aug 18, 2016 at 08:11:26AM -0400, npostavs@users.sourceforge.net wrote:
> Andreas Schwab <schwab@linux-m68k.org> writes:

> > On Aug 12 2016, Noam Postavsky <npostavs@users.sourceforge.net> wrote:

> >> On Thu, Aug 11, 2016 at 8:14 AM, Alan Mackenzie <acm@muc.de> wrote:
> >>> Yes.  In the line "k() < l() &&", the "<" is being recognised as a
> >>> template opener.

> >> Is it possible to say that "<" can't be a template opener when it
> >> comes after a close paren? (I can't think of a case in C++ where that
> >> would fail, though I'm not 100% certain there isn't one)

> > operator()<foo>

> So could we say "<" can't be a template opener when it comes after a
> close paren except for the close paren of "operator()"?

We could, but I can't see it helping very much (though it might help a
little bit).

There are probably quite a lot of special cases like that where it is
possible to say for sure that the "<" does/doesn't introduce a template
construct.  But that will leave a lot of ambiguous cases.  The more we
try to analyse these, the closer we get to building a compiler inside CC
Mode.  For example, the example given might have been "k < l() && ....",
leaving no syntactic clues about the templateicity of "<".

Analysing the C++ syntax to determine these determinable cases would be
a lot of work, and it would be a lot of work to implement it, too.

The C++ standards people haven't thought it worthwhile to preserve
unambigious syntax in their language, so there is no way CC Mode can get
it right every time.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#24195: 25.0.95; Wrong indentation after a 'less < than' comparison (c++-mode)

[npostavs]

tags 24195 wontfix
quit

Alan Mackenzie <acm@muc.de> writes:

>> So could we say "<" can't be a template opener when it comes after a
>> close paren except for the close paren of "operator()"?
>
> We could, but I can't see it helping very much (though it might help a
> little bit).
>
> There are probably quite a lot of special cases like that where it is
> possible to say for sure that the "<" does/doesn't introduce a template
> construct.  But that will leave a lot of ambiguous cases.  The more we
> try to analyse these, the closer we get to building a compiler inside CC
> Mode.  For example, the example given might have been "k < l() && ....",
> leaving no syntactic clues about the templateicity of "<".
>
> Analysing the C++ syntax to determine these determinable cases would be
> a lot of work, and it would be a lot of work to implement it, too.
>
> The C++ standards people haven't thought it worthwhile to preserve
> unambigious syntax in their language, so there is no way CC Mode can get
> it right every time.

Makes sense, I've been out of C++ for some time, so I kind of forgot how
ridiculous the syntax is.  Marking as wontfix.