Re: [obv] compile-print.exp: xfail->kfail for '@' GDB array operator

[Yao Qi <qiyaoltc@gmail.com>]

Jan Kratochvil <jan.kratochvil@redhat.com> writes:

> 'compile print' should one day replace the standard 'print' command, like in
> LLDB.  Otherwise 'compile print' makes no sense.
>
> Now we can argue whether the '@' GDB operator is useful or not but I think
> majority of GDB users considers it as useful.

'@' is useful in command print, and it is reasonable for me to replace
command print with 'compile print' one day, I agree on them.  If gcc
doesn't accept '@', 'compile print' shouldn't as well, but 'print' can.

Command 'print' can be built on top of the 'compile print' stuff, with
extra functionality to transform '@' to a valid language form.  Is it
possible?

Anyway, I suggest we consider support '@' when we really start
considering replace 'print' command with 'compile print' command.  Once
we support '@' in 'compile print', we can't remove it.  I am inclined to
postpone the decision to some time we really need it.

>> It will be really confusing if we add some other things (like '@' in this
>> case) which is out of the scope of the language.
>
> So why were these operators added to the GDB expression evaluator in the first
> place?
>

I don't know, but GDB expression (which supports '@') is not a language,
so it is flexible to add and remove operators.  Commands 'compile XXX'
are different, because their input is source language, and IMO we
shouldn't add any extensions to the source language.

>
>> > -	xfail "$test (gcc does not support '@')"
>> > +	kfail compile/18489 "$test"
>> 
>> I think xfail is correct as gcc doesn't support '@'.
>
> This does not match the original plan of the 'compile' project.

Where is the original plan?
https://sourceware.org/gdb/wiki/GCCCompileAndExecute is the only thing I
can find, but I don't see the anything about replacing command 'print' with
'compile print'.

-- 
Yao (齐尧)