Fix build failure on macOS
Commit Message
PR build/25250 notes that the gdb 9 pre-release fails to build on
macOS, due to a name clash between field_kind::STRING and the STRING
token in ada-exp.y. I am not sure (I couldn't reproduce this myself),
but presumably this is due to differences caused by the version of
bison in use there.
This patch works around the problem by renaming the field_kind
enumerator. I chose to rename this one because it is used in
relatively few places -- it's just an implementation detail of the
style code.
Let me know what you think. I intend to check this in on the gdb 9
branch as well.
gdb/ChangeLog
2019-12-18 Tom Tromey <tromey@adacore.com>
PR build/25250:
* ui-out.c (ui_out::vmessage): Update.
* ui-out.h (enum class) <FIELD_STRING>: Rename from STRING.
(string_field): Update.
Change-Id: Iae9f36f1b793e22c61fee0de2ab2d508668ee7e4
---
gdb/ChangeLog | 7 +++++++
gdb/ui-out.c | 2 +-
gdb/ui-out.h | 6 ++++--
3 files changed, 12 insertions(+), 3 deletions(-)
Comments
On 12/18/19 3:05 PM, Tom Tromey wrote:
> Let me know what you think. I intend to check this in on the gdb 9
> branch as well.
Whoops, should have thought of this.
> @@ -78,7 +78,9 @@ enum ui_out_type
> enum class field_kind
> {
> SIGNED,
> - STRING,
> + /* This has a funny name to avoid clashes with tokens named
> + "STRING". See PR build/25250. */
> + FIELD_STRING,
> };
I'd rather rename SIGNED to FIELD_SIGNED as well, for consistency.
It no longer looks funny that way.
Thanks,
Pedro Alves
On 2019-12-18 10:05 a.m., Tom Tromey wrote:
> PR build/25250 notes that the gdb 9 pre-release fails to build on
> macOS, due to a name clash between field_kind::STRING and the STRING
> token in ada-exp.y. I am not sure (I couldn't reproduce this myself),
> but presumably this is due to differences caused by the version of
> bison in use there.
>
> This patch works around the problem by renaming the field_kind
> enumerator. I chose to rename this one because it is used in
> relatively few places -- it's just an implementation detail of the
> style code.
>
> Let me know what you think. I intend to check this in on the gdb 9
> branch as well.
The difference between macOS's bison (2.3) and later version (I'm not sure at
which release the behavior changed) is that the order of the prologue (where
we #include stuff) versus the bison declarations (#define STRING xyz) changed.
Bison 2.3 puts the declarations before the prologue, which can break included
files as we see here. Later versions put the prologue before (actually the
exact location of the code can be controlled by using %code).
I don't really mind this particular fix, as it doesn't add complexity. But if
in the future the macOS version gives us some more major headache, I would be
comfortable just saying that we don't support it, and adding a %require statement
in the grammar file. Recent bison versions are easily available through Homebrew
and macports.
Simon
Simon> I don't really mind this particular fix, as it doesn't add complexity. But if
Simon> in the future the macOS version gives us some more major headache, I would be
Simon> comfortable just saying that we don't support it, and adding a %require statement
Simon> in the grammar file.
This sounds reasonable to me. I imagine it's inevitable as macOS
doesn't update GNU tools any more.
thanks,
Tom
@@ -736,7 +736,7 @@ ui_out::vmessage (const ui_file_style &in_style, const char *format,
field_signed (f->name, f->val);
}
break;
- case field_kind::STRING:
+ case field_kind::FIELD_STRING:
{
auto *f = (string_field_s *) bf;
field_string (f->name, f->str);
@@ -78,7 +78,9 @@ enum ui_out_type
enum class field_kind
{
SIGNED,
- STRING,
+ /* This has a funny name to avoid clashes with tokens named
+ "STRING". See PR build/25250. */
+ FIELD_STRING,
};
/* The base type of all fields that can be emitted using %pF. */
@@ -126,7 +128,7 @@ string_field (const char *name, const char *str,
string_field_s &&tmp = {})
{
tmp.name = name;
- tmp.kind = field_kind::STRING;
+ tmp.kind = field_kind::FIELD_STRING;
tmp.str = str;
return &tmp;
}