From: Eli Zaretskii <eliz@gnu.org>
To: Paul Hilfinger <hilfingr@gnat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Assignment of aggregates in Ada
Date: Sat, 31 Dec 2005 16:04:00 -0000 [thread overview]
Message-ID: <uirt6srym.fsf@gnu.org> (raw)
In-Reply-To: <20051230101320.6A16348CBE6@nile.gnat.com> (message from Paul Hilfinger on Fri, 30 Dec 2005 05:13:20 -0500 (EST))
> From: Paul Hilfinger <hilfingr@gnat.com>
> Date: Fri, 30 Dec 2005 05:13:20 -0500 (EST)
>
> The following set of changes allows assignments from aggregates in
> Ada. I will commit in a few days if there is no objection.
Thanks.
> + else if (nsyms == 0 || SYMBOL_CLASS (syms[0].sym) != LOC_BLOCK)
> + {
> + if (context == NULL)
> + error ("No file or function \"%s\".", raw_name);
> + else
> + error ("No function \"%s\" in specified context.", raw_name);
> + }
> + else
> + {
> + if (nsyms > 1)
> + warning ("Function name \"%s\" ambiguous here", raw_name);
> + return SYMBOL_BLOCK_VALUE (syms[0].sym);
> + }
Please be sure to include in _() all strings that are messages
displayed to the user. This is in preparation for GDB's i18n, at some
future date.
> + error ("Illegal attempt to select from type: \"%s\".", name0.ptr);
Using ``illegal'' in a context that doesn't deal with laws is a no-no
in GNU projects. ``Invalid'' is the usual replacement.
> Index: gdb/doc/gdb.texinfo
Please include suitable entries for gdb/doc/ChangeLog.
> @item
> -There are no record or array aggregates.
> +There is limited support for array and record aggregates. They are
> +permitted only on the right sides of assignments. Changing a
> +discriminant's value by means of assignment of an aggregate has an
> +undefined effect if that discriminant is used within the record.
> +However, one can first modify discriminants by directly assigning to
> +them (which normally would not be allowed in Ada), and then performing an
> +aggregate assignment. @value{GDBN} is very loose about the usual
> +rules concerning aggregates. You may mention only some of the
> +components of an array or record aggregate; the rest will retain their
> +original values upon assignment. You may freely use dynamic values as
> +indices in component associations. You may uses overlapping or
> +redundant component associations, although which component values are
> +assigned in such cases is not defined.
I think an example or two here would help clarify what you are saying.
Also a @cindex entry might be a good idea, for example:
@cindex array and record aggregates (Ada)
Is the description above the only user-visible effect of these massive
changes? If not, I'd like to document the rest as well.
next prev parent reply other threads:[~2005-12-30 12:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-31 6:21 Paul Hilfinger
2005-12-31 16:04 ` Eli Zaretskii [this message]
2005-12-31 6:26 Paul Hilfinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=uirt6srym.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=hilfingr@gnat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox