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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

Hi Yao,

I have replied to all your arguments but I think it is just enough to say:
	'compile print' is a work in progress to become future 'print'.


On Fri, 05 Jun 2015 18:13:07 +0200, Yao Qi wrote:
> '@' 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.

That depends what 'compile print' should do.  IMO it is "future 'print'".
So I do not understand why you say:
	'compile print' shouldn't [...], but 'print' can.


> Command 'print' can be built on top of the 'compile print' stuff,

'print' should be replaced by 'compile print'.  'compile print' is a work in
progress towards that goal.

If you want we can create 'compile print2' which will be "future 'print'"
while 'compile print' can remain ISO C (or whatever language GCC is configure
to accept) clean.  But then I do not see what 'compile print' would be good
for, 'compile print2' would supersede it in all aspects.

Besides that there is currently no kind of 'print' command unsupporting GDB
extensions so I do not understand why you want 'compile print' to have one.


> with extra functionality to transform '@' to a valid language form.  Is it
> possible?

Everything is possible but I do not see usefulness of multiple commands where
one is a subset of functionality of other.  The general goal should be
reducing the number of commands/options of GDB, not the opposite.


> 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.

'compile print' should be already useful in some cases (such as evaluating
macros containing statement expressions) although I admit I haven't yet had an
opportunity to utilize it (primarily because there is no inferior C++
'compile' support yet).

I was proposing to implement the discussed command
	set compile print {never|always|preferred|deferred}
as it makes sense already; but I was assigned to other priorities so far.


> 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.

I do not understand why you find the goals of 'compile print' and 'print' to
be different.


> 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'.

The plan is to support all the features of LLDB which uses clang/llvm for its
'print' command.  Although it may not be a great argument as LLDB does not
support the '@' operator at all.


Jan