The next patch will want to do language->print_type(type, ...), to
print a type in a given language, avoiding a dependency on the current
language. That doesn't work correctly currently, however, because
most language implementations of language_defn::print_type call
c_print_type without passing down the language. There are two
overloads of c_print_type, one that takes a language, and one that
does not. The one that does not uses the current language, defeating
the point of calling language->print_type()...
This commit removes the c_print_type overload that does not take a
language, and adjusts the codebase throughout to always pass down a
language. In most places, there's already an enum language handy.
language_defn::print_type implementations naturally pass down
this->la_language. In a couple spots, like in ada-typeprint.c and
rust-lang.c there's no enum language handy, but the code is written
for a specific language, so we just hardcode the language.
In gnuv3_print_method_ptr, I wasn't sure whether we could hardcode C++
here, and we don't have an enum language handy, so I made it use the
current language, just like today. Can always be improved later.
Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b
This adds an implementation of the value_print method to Rust. As
described in PR rust/22254, this removes a bit of weird-looking output
from some "print"s -- because c_value_print is bypassed. I don't have
a test for the bug that inspired this patch, because I only know how
to reproduce it when using a relatively old Rust compiler. However,
the new "cast-printing" code in value_print is required, because
omitting this causes some existing tests to fail.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22254
The current nightly Rust compiler (aka 1.61) added better DWARF
representation for unsized types. Fixing this is PR rust/21466; but
the code is actually the same as what is required to make slice
printing more useful, which is PR rust/23871. This patch implements
this. I tested this against various Rust compilers: 1.48, current
stable, current beta, and current nightly.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21466
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23871
This removes a bit of dead code from the Rust value printer. This
code wasn't always dead -- it fixed a real bug, and a test case was
added for it. However, once val_print was removed, it became
unnecessary.
Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions. This is done under the name
"gdb_printf". Most of this patch was written by script.
Now that filtered and unfiltered output can be treated identically, we
can unify the putc family of functions. This is done under the name
"gdb_putc". Most of this patch was written by script.
Now that filtered and unfiltered output can be treated identically, we
can unify the puts family of functions. This is done under the name
"gdb_puts". Most of this patch was written by script.
Add a getter and a setter for a symbol's type. Remove the corresponding
macro and adjust all callers.
Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
A few Rust operations do a bit of work in their 'evaluate' functions
and then call another function -- but are also the only caller. This
patch simplifies this code by removing the extra layer.
Tested on x86-64 Fedora 34. I'm checking this in.
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
Change a few relatively obvious spots using value contents to propagate
the use array_view a bit more.
Change-Id: I5338a60986f06d5969fec803d04f8423c9288a15
The bug fixed by this [1] patch was caused by an out-of-bounds access to
a value's content. The code gets the value's content (just a pointer)
and then indexes it with a non-sensical index.
This made me think of changing functions that return value contents to
return array_views instead of a plain pointer. This has the advantage
that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view
are checked, making bugs more apparent / easier to find.
This patch changes the return types of these functions, and updates
callers to call .data() on the result, meaning it's not changing
anything in practice. Additional work will be needed (which can be done
little by little) to make callers propagate the use of array_view and
reap the benefits.
[1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html
Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
Add accessors for the various location values in struct field. This
lets us assert that when we get a location value of a certain kind (say,
bitpos), the field's location indeed contains a value of that kind.
Remove the SET_FIELD_* macros, instead use the new setters directly.
Update the FIELD_* macros used to access field locations to go through
the getters. They will be removed in a subsequent patch.
There are places where the FIELD_* macros are used on call_site_target
structures, because it contains members of the same name (loc_kind and
loc). For now, I have replicated the getters/setters in
call_site_target. But we could perhaps eventually factor them in a
"location" structure that can be used at both places.
Note that the field structure, being zero-initialized, defaults to a
bitpos location with value 0. While writing this patch, I tried to make
it default to an "unset" location, to catch places where we would miss
setting a field's location. However, I found that some places relied on
the default being "bitpos 0", so I left it as-is. This change could
always be done as follow-up work, making these places explicitly set the
"bitpos 0" location.
I found two issues to fix:
- I got some failures in the gdb.base/infcall-nested-structs-c++.exp
test. They were caused by two functions in amd64-tdep.c using
TYPE_FIELD_BITPOS before checking if the location is of the bitpos
kind, which they do indirectly through `field_is_static`. Simply
move getting the bitpos below the field_is_static call.
- I got a failure in gdb.xml/tdesc-regs.exp. It turns out that in
make_gdb_type_enum, we set enum field values using SET_FIELD_BITPOS,
and later access them through FIELD_ENUMVAL. Fix that by using
set_loc_enumval to set the value.
Change-Id: I53d3734916c46457576ba11dd77df4049d2fc1e8
Remove the `TYPE_FIELD_NAME` and `FIELD_NAME` macros, changing all the
call sites to use field::name directly.
Change-Id: I6900ae4e1ffab1396e24fb3298e94bf123826ca6
Add the `name` and `set_name` methods on `struct field`, in order to
remove `FIELD_NAME` and `TYPE_FIELD_NAME` macros. In this patch, the
macros are changed to use `field::name`, so all the call sites that are
used to set the field's name are changed to use `field::set_name`.
The next patch will remove the macros completely.
Note that because of the name clash between the existing field named
`name` and the new method, I renamed the field `m_name`. It is not
private per-se, because we can't make `struct field` a non-POD yet, but
it should be considered private anyway (not accessed outside `struct
field`).
Change-Id: If16ddbca4e0c39d0ff9da420bb5cdebe5b9b0896
Following on from the previous commit, this commit changes the API of
value_struct_elt to take gdb::optional<gdb::array_view<value *>>
instead of a pointer to the gdb::array_view.
This makes the optional nature of the array_view parameter explicit.
This commit is purely a refactoring commit, there should be no user
visible change after this commit.
I have deliberately kept this refactor separate from the previous two
commits as this is a more extensive change, and I'm not 100% sure that
using gdb::optional for the parameter type, instead of a pointer, is
going to be to everyone's taste. If there's push back on this patch
then this one can be dropped from the series.
gdb/ChangeLog:
* ada-lang.c (desc_bounds): Use '{}' instead of NULL to indicate
an empty gdb::optional when calling value_struct_elt.
(desc_data): Likewise.
(desc_one_bound): Likewise.
* eval.c (structop_base_operation::evaluate_funcall): Pass
gdb::array_view, not a gdb::array_view* to value_struct_elt.
(eval_op_structop_struct): Use '{}' instead of NULL to indicate
an empty gdb::optional when calling value_struct_elt.
(eval_op_structop_ptr): Likewise.
* f-lang.c (fortran_structop_operation::evaluate): Likewise.
* guile/scm-value.c (gdbscm_value_field): Likewise.
* m2-lang.c (eval_op_m2_high): Likewise.
(eval_op_m2_subscript): Likewise.
* opencl-lang.c (opencl_structop_operation::evaluate): Likewise.
* python/py-value.c (valpy_getitem): Likewise.
* rust-lang.c (rust_val_print_str): Likewise.
(rust_range): Likewise.
(rust_subscript): Likewise.
(eval_op_rust_structop): Likewise.
(rust_aggregate_operation::evaluate): Likewise.
* valarith.c (value_user_defined_op): Likewise.
* valops.c (search_struct_method): Change parameter type, update
function body accordingly, and update header comment.
(value_struct_elt): Change parameter type, update function body
accordingly.
* value.h (value_struct_elt): Update declaration.
An upstream Rust bug notes notes that the Python pretty-printing
feature is broken for values that appear as members of certain types
in Rust.
The bug here is that some of the Rust value-printing code calls
value_print_inner, a method on rust_language. This bypasses the
common code that calls into Python.
I'm checking this in.
gdb/ChangeLog
2021-05-14 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_language::val_print_struct)
(rust_language::print_enum): Use common_val_print, not
value_print_inner.
gdb/testsuite/ChangeLog
2021-05-14 Tom Tromey <tom@tromey.com>
* gdb.rust/pp.exp: New file.
* gdb.rust/pp.py: New file.
* gdb.rust/pp.rs: New file.
This commit adds a flag to the ptype command in order to print the
offsets and sizes of struct members using the hexadecimal notation. The
'x' flag ensures use of the hexadecimal notation while the 'd' flag
ensures use of the decimal notation. The default is to use decimal
notation.
Before this patch, gdb only uses decimal notation, as pointed out in PR
gdb/22640.
Here is an example of this new behavior with hex output turned on:
(gdb) ptype /ox struct type_print_options
/* offset | size */ type = struct type_print_options {
/* 0x0000: 0x0 | 0x0004 */ unsigned int raw : 1;
/* 0x0000: 0x1 | 0x0004 */ unsigned int print_methods : 1;
/* 0x0000: 0x2 | 0x0004 */ unsigned int print_typedefs : 1;
/* 0x0000: 0x3 | 0x0004 */ unsigned int print_offsets : 1;
/* 0x0000: 0x4 | 0x0004 */ unsigned int print_in_hex : 1;
/* XXX 3-bit hole */
/* XXX 3-byte hole */
/* 0x0004 | 0x0004 */ int print_nested_type_limit;
/* 0x0008 | 0x0008 */ typedef_hash_table *local_typedefs;
/* 0x0010 | 0x0008 */ typedef_hash_table *global_typedefs;
/* 0x0018 | 0x0008 */ ext_lang_type_printers *global_printers;
/* total size (bytes): 32 */
}
This patch also adds the 'set print type hex' and 'show print type hex'
commands in order to set and inspect the default behavior regarding the
use of decimal or hexadecimal notation when printing struct sizes and
offsets.
Tested using on x86_64.
gdb/ChangeLog:
PR gdb/22640
* typeprint.h (struct type_print_options): Add print_in_hex
flag.
(struct print_offset_data): Add print_in_hex flag, add a
constructor accepting a type_print_options* argument.
* typeprint.c (type_print_raw_options, default_ptype_flags): Set
default value for print_in_hex.
(print_offset_data::indentation): Allow more horizontal space.
(print_offset_data::print_offset_data): Add ctor.
(print_offset_data::maybe_print_hole, print_offset_data::update):
Handle the print_in_hex flag.
(whatis_exp): Handle 'x' and 'd' flags.
(print_offsets_and_sizes_in_hex): Declare.
(set_print_offsets_and_sizes_in_hex): Create.
(show_print_offsets_and_sizes_in_hex): Create.
(_initialize_typeprint): Update help message for the ptype
command, register the 'set print type hex' and 'show print type
hex' commands.
* c-typeprint.c (c_print_type, c_type_print_base_struct_union)
(c_type_print_base): Construct the print_offset_data
object using the type_print_optons parameter.
* rust-lang.c (rust_language::print_type): Construct the
print_offset_data object using the type_print_optons parameter.
* NEWS: Mention the new flags of the ptype command.
gdb/doc/ChangeLog:
PR gdb/22640
* gdb.texinfo (Symbols): Describe the 'x' and 'd' flags of the
ptype command, describe 'set print type hex' and 'show print
type hex' commands. Update 'ptype/o' examples.
gdb/testsuite/ChangeLog:
PR gdb/22640
* gdb.base/ptype-offsets.exp: Add tests to verify the behavior
of 'ptype/ox' and 'ptype/od'. Check that 'set print type hex'
changes the default behavior of 'ptype/o'. Update to take into
account new horizontal layout.
* gdb.rust/simple.exp: Update ptype test to check new horizontal
layout.
* gdb.rust/union.exp: Same.
Now that the Rust parser has switched to the new style, there is no
need for the old Rust evaluation code.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* rust-lang.h (class rust_language) <expression_ops,
exp_descriptor_tab>: Remove.
* rust-lang.c (rust_evaluate_funcall): Remove.
(rust_range, rust_subscript, eval_op_rust_complement): Don't use
EVAL_SKIP.
(rust_evaluate_subexp): Remove.
(rust_aggregate_operation::evaluate): Don't use EVAL_SKIP.
(rust_operator_length, rust_dump_subexp_body, rust_print_subexp)
(rust_operator_check, rust_language::exp_descriptor_tab): Remove.
This adds the special code needed to handle the Rust function call
operation.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_structop::evaluate_funcall): New method.
* rust-exp.h (class rust_structop) <evaluate_funcall>: Declare
method.
This adds class rust_aggregate_operation, which implements
OP_AGGREGATE for Rust.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_aggregate_operation::evaluate): New method.
* rust-exp.h (class rust_aggregate_operation): New.
This implements the field operations STRUCTOP_STRUCT and
STRUCTOP_ANONYMOUS, for Rust.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* rust-lang.c (eval_op_rust_struct_anon, eval_op_rust_structop):
No longer static.
* rust-exp.h (class rust_struct_anon): New.
(class rust_structop): New.
This adds class rust_range_operation, which implements OP_RANGE.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_range): No longer static.
* rust-exp.h (class rust_range_operation): New.
This adds class rust_subscript_operation, which implements
BINOP_SUBSCRIPT for Rust.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_subscript): No longer static.
* rust-exp.h (class rust_subscript_operation): New.
This adds class rust_unop_ind_operation, which implements UNOP_IND for
Rust. Rust requires a special case here to handle trait objects.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* rust-lang.c (eval_op_rust_ind): No longer static. Add "opcode"
parameter.
(rust_evaluate_subexp): Update.
* rust-exp.h (class rust_unop_ind_operation): New.
This splits STRUCTOP_STRUCT into a new function for future use.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* rust-lang.c (eval_op_rust_structop): New function.
(rust_evaluate_subexp): Use it.
This splits STRUCTOP_ANONYMOUS into a new function for future use.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* rust-lang.c (eval_op_rust_struct_anon): New function.
(rust_evaluate_subexp): Use it.
This splits OP_ARRAY into a new function for future use.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* rust-lang.c (eval_op_rust_array): New function.
(rust_evaluate_subexp): Use it.
This splits UNOP_COMPLEMENT into a new function for future use.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* rust-lang.c (eval_op_rust_complement): New function.
(rust_evaluate_subexp): Use it.
This splits UNOP_IND into a new function for future use.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* rust-lang.c (eval_op_rust_ind): New function.
(rust_evaluate_subexp): Use it.
This changes the parameters to rust_subscript, making it more suitable
for reuse by the (coming) new expression code. In particular,
rust_subscript no longer evaluates its subexpressions. Instead, they
are passed in.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_subscript): Change parameters.
(rust_evaluate_subexp): Update.
This changes the parameters to rust_range, making it more suitable for
reuse by the (coming) new expression code. In particular, rust_range
no longer evaluates its subexpressions. Instead, they are passed in.
gdb/ChangeLog
2021-03-08 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_range): Change parameters.
(rust_evaluate_subexp): Update.
I think this makes the names of the methods clearer, especially for the
arch. The type::arch method (which gets the arch owner, or NULL if the
type is not arch owned) is easily confused with the get_type_arch method
(which returns an arch no matter what). The name "arch_owner" will make
it intuitive that the method returns NULL if the type is not arch-owned.
Also, this frees the type::arch name, so we will be able to morph the
get_type_arch function into the type::arch method.
gdb/ChangeLog:
* gdbtypes.h (struct type) <arch>: Rename to...
<arch_owner>: ... this, update all users.
<objfile>: Rename to...
<objfile_owner>: ... this, update all users.
Change-Id: Ie7c28684c7b565adec05a7619c418c69429bd8c0
Change all users to use the type::objfile method instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_OBJFILE): Remove, change all users to use the
type::objfile method instead.
Change-Id: I6b3f580913fb1fb0cf986b176dba8db68e1fabf9
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
Move the rust_language class declaration into the rust-lang.h header
file. This allows for the function implementations called directly in
rust-lang.c and rust-exp.y without the need for trampoline functions.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* rust-exp.y (rust_parse): Rename to...
(rust_language::parser): ...this.
* rust-lang.c (-rust_printstr): Rename to...
(rust_language::printstr): ...this.
(rust_value_print_inner): Delete declaration.
(val_print_struct): Rename to...
(rust_language::val_print_struct): ...this. Update calls to
member functions.
(rust_print_enum): Rename to...
(rust_language::print_enum): ...this. Update calls to member
functions.
(rust_value_print_inner): Rename to...
(rust_language::value_print_inner): ...this. Update calls to
member functions.
(exp_descriptor_rust): Rename to...
(rust_language::exp_descriptor_tab): ...this.
(class rust_language): Move to rust-lang.h.
(rust_language::language_arch_info): Implementation moved to here
from class declaration.
(rust_language::print_type): Likewise.
(rust_language::emitchar): Likewise.
(rust_language::is_string_type_p): Likewise.
* rust-lang.h: Add 'demangle.h', 'language.h', 'value.h', and
'c-lang.h' includes.
(rust_parse): Delete declaration.
(class rust_language): Class declaration moved here from
rust-lang.c.
Now that every use of the LA_EMIT_CHAR macro is within a language_defn
member function we can simply call the emitchar member function
directly instead of using the LA_EMIT_CHAR macro.
If we are ever inside a language object, for example, cplus_language,
while current_language points at something other than cplus_language
then this commit will result in a change in behaviour. However, I
believe if we did have such a difference then this would be a bug in
GDB. AS such I'm going to claim there _should_ be no user visible
changes from this commit.
gdb/ChangeLog:
* c-lang.c (language_defn::printchar): Call emitchar, not
LA_EMIT_CHAR.
* f-lang.h (f_language::printchar): Likewise.
* language.h (LA_EMIT_CHAR): Delete macro.
* rust-lang.c (rust_language::printchar): Call emitchar, not
LA_EMIT_CHAR.
After seeing Simon's patch, I thought maybe it was finally time to
remove printfi_filtered and fprintfi_filtered, in favor of using the
"%*s" approach to indenting.
In this patch I took the straightforward approach of always adding a
leading "%*s", even when the format already started with "%s", to
avoid the trickier form of:
printf ("%*s", -indent, string)
Regression tested on x86-64 Fedora 32.
Let me know what you think.
gdb/ChangeLog
2020-12-17 Tom Tromey <tromey@adacore.com>
* gdbtypes.c (print_args, dump_fn_fieldlists, print_cplus_stuff)
(print_gnat_stuff, print_fixed_point_type_info)
(recursive_dump_type): Update.
* go32-nat.c (go32_sysinfo, display_descriptor): Update.
* c-typeprint.c (c_type_print_base_struct_union)
(c_type_print_base_1): Update.
* rust-lang.c (rust_internal_print_type): Update.
* f-typeprint.c (f_language::f_type_print_base): Update.
* utils.h (fprintfi_filtered, printfi_filtered): Remove.
* m2-typeprint.c (m2_record_fields): Update.
* p-typeprint.c (pascal_type_print_base): Update.
* compile/compile-loc2c.c (push, pushf, unary, binary)
(do_compile_dwarf_expr_to_c): Update.
* utils.c (fprintfi_filtered, printfi_filtered): Remove.
enum exp_opcode is created from all the .def files, but then each
language is required to implement its own op_name function to turn an
enum value to a string. This seemed over-complicated to me, and this
patch removes the per-language functions in favor of simply using the
.def names for all languages. Note that op_name is only used for
dumping expressions, which is a maintainer/debug feature.
Furthermore, I don't think there was any case where the .def name and
the string name differed.
gdb/ChangeLog
2020-11-30 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_op_name): Remove.
(exp_descriptor_rust): Update.
* parser-defs.h (op_name_standard): Don't declare.
(struct exp_descriptor) <op_name>: Remove.
* parse.c (exp_descriptor_standard): Update.
* opencl-lang.c (exp_descriptor_opencl): Update.
* m2-lang.c (m2_language::exp_descriptor_modula2): Update.
* f-lang.c (op_name_f): Remove.
(f_language::exp_descriptor_tab): Update.
* expression.h (op_name): Update.
* expprint.c (op_name): Rewrite.
(op_name_standard): Remove.
(dump_raw_expression, dump_subexp): Update.
* c-lang.c (exp_descriptor_c): Update.
* ax-gdb.c (gen_expr): Update.
* ada-lang.c (ada_op_name): Remove.
(ada_exp_descriptor): Update.
While working on another series, I noticed that c-lang.h does not need
to include parser-defs.h. This patch makes this change, and fixes up
the two .c files that needed this include. Tested by rebuilding.
gdb/ChangeLog
2020-11-25 Tom Tromey <tom@tromey.com>
* d-lang.c: Include parser-defs.h.
* rust-lang.c: Include parser-defs.h.
* c-lang.h: Do not include parser-defs.h.
Consider the following GDB session:
$ gdb
(gdb) set language c
(gdb) ptype void
type = void
(gdb) set language fortran
(gdb) ptype void
No symbol table is loaded. Use the "file" command.
(gdb)
With no symbol file loaded GDB and the language set to C GDB knows
about the type void, while when the language is set to Fortran GDB
doesn't know about the void, why is that?
In f-lang.c, f_language::language_arch_info, we do have this line:
lai->primitive_type_vector [f_primitive_type_void]
= builtin->builtin_void;
where we add the void type to the list of primitive types that GDB
should always know about, so what's going wrong?
It turns out that the primitive types are stored in a C style array,
indexed by an enum, so Fortran uses `enum f_primitive_types'. The
array is allocated and populated in each languages language_arch_info
member function. The array is allocated with an extra entry at the
end which is left as a NULL value, and this indicates the end of the
array of types.
Unfortunately for Fortran, a type is not assigned for each element in
the enum. As a result the final populated array has gaps in it, gaps
which are initialised to NULL, and so every time we iterate over the
list (for Fortran) we stop early, and never reach the void type.
This has been the case since 2007 when this functionality was added to
GDB in commit cad351d11d.
Obviously I could just fix Fortran by ensuring that either the enum is
trimmed, or we create types for the missing types. However, I think a
better approach would be to move to C++ data structures and removed
the fixed enum indexing into the array approach.
After this commit the primitive types are pushed into a vector, and
GDB just iterates over the vector in the obvious way when it needs to
hunt for a type. After this commit all the currently defined
primitive types can be found when the language is set to Fortran, for
example:
$ gdb
(gdb) set language fortran
(gdb) ptype void
type = void
(gdb)
A new test checks this functionality.
I didn't see any other languages with similar issues, but I could have
missed something.
gdb/ChangeLog:
* ada-exp.y (find_primitive_type): Make parameter const.
* ada-lang.c (enum ada_primitive_types): Delete.
(ada_language::language_arch_info): Update.
* c-lang.c (enum c_primitive_types): Delete.
(c_language_arch_info): Update.
(enum cplus_primitive_types): Delete.
(cplus_language::language_arch_info): Update.
* d-lang.c (enum d_primitive_types): Delete.
(d_language::language_arch_info): Update.
* f-lang.c (enum f_primitive_types): Delete.
(f_language::language_arch_info): Update.
* go-lang.c (enum go_primitive_types): Delete.
(go_language::language_arch_info): Update.
* language.c (auto_or_unknown_language::language_arch_info):
Update.
(language_gdbarch_post_init): Use obstack_new, use array indexing.
(language_string_char_type): Add header comment, call function in
language_arch_info.
(language_bool_type): Likewise
(language_arch_info::bool_type): Define.
(language_lookup_primitive_type_1): Delete.
(language_lookup_primitive_type): Rewrite as a templated function
to call function in language_arch_info, then instantiate twice.
(language_arch_info::type_and_symbol::alloc_type_symbol): Define.
(language_arch_info::lookup_primitive_type_and_symbol): Define.
(language_arch_info::lookup_primitive_type): Define twice with
different signatures.
(language_arch_info::lookup_primitive_type_as_symbol): Define.
(language_lookup_primitive_type_as_symbol): Rewrite to call a
member function in language_arch_info.
* language.h (language_arch_info): Complete rewrite.
(language_lookup_primitive_type): Make templated.
* m2-lang.c (enum m2_primitive_types): Delete.
(m2_language::language_arch_info): Update.
* opencl-lang.c (OCL_P_TYPE): Delete.
(enum opencl_primitive_types): Delete.
(opencl_type_data): Delete.
(builtin_opencl_type): Delete.
(lookup_opencl_vector_type): Update.
(opencl_language::language_arch_info): Update, lots of content
moved from...
(build_opencl_types): ...here. This function is now deleted.
(_initialize_opencl_language): Delete.
* p-lang.c (enum pascal_primitive_types): Delete.
(pascal_language::language_arch_info): Update.
* rust-lang.c (enum rust_primitive_types): Delete.
(rust_language::language_arch_info): Update.
gdb/testsuite/ChangeLog:
* gdb.fortran/types.exp: Add more tests.
GDB already has a global symbol `demangle` (a boolean), having a
language method called `demangle` is not a good idea as we often want
to reference `demangle` the control variable inside `demangle` the
member function.
This commit renames `demangle` the member function to
`demangle_symbol`.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language::demangle): Rename to...
(ada_language::demangle_symbol): ...this.
* c-lang.c (cplus_language::demangle): Rename to...
(cplus_language::demangle_symbol): ...this.
* d-lang.c (d_language::demangle): Rename to...
(d_language::demangle_symbol): ...this.
* f-lang.c (f_language::demangle): Rename to...
(f_language::demangle_symbol): ...this.
* go-lang.c (go_language::demangle): Rename to...
(go_language::demangle_symbol): ...this.
* language.c (language_demangle): Update call to demangle_symbol.
(auto_or_unknown_language::demangle): Rename to...
(auto_or_unknown_language::demangle_symbol): ...this.
* language.h (language_defn::demangle): Rename to...
(language_defn::demangle_symbol): ...this.
* objc-lang.c (objc_language::demangle): Rename to...
(objc_language::demangle_symbol): ...this.
* rust-lang.c (rust_language::demangle): Rename to...
(rust_language::demangle_symbol): ...this.
To avoid confusion with other parts of GDB relating to types and
ranges, rename this enum to make it clearer that it is a set of
individual flags rather than an enumeration of different types of
range.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* expprint.c (print_subexp_standard): Change enum range_type to
range_flag and rename variables to match.
(dump_subexp_body_standard): Likewise.
* expression.h (enum range_type): Rename to...
(enum range_flag): ...this.
(range_types): Rename to...
(range_flags): ...this.
* f-lang.c (value_f90_subarray): Change enum range_type to
range_flag and rename variables to match.
* parse.c (operator_length_standard): Likewise.
* rust-exp.y (rust_parser::convert_ast_to_expression): Change enum
range_type to range_flag.
* rust-lang.c (rust_evaluate_funcall): Likewise.
(rust_range): Likewise.
(rust_compute_range): Likewise.
(rust_subscript): Likewise.
The expression range_type enum represents the following ideas:
- Lower bound is set to default,
- Upper bound is set to default,
- Upper bound is exclusive.
There are currently 6 entries in the enum to represent the combination
of all those ideas.
In a future commit I'd like to add stride information to the range,
this could in theory appear with any of the existing enum entries, so
this would take us to 12 enum entries.
This feels like its getting a little out of hand, so in this commit I
switch the range_type enum over to being a flags style enum. There's
one entry to represent no flags being set, then 3 flags to represent
the 3 ideas above. Adding stride information will require adding only
one more enum flag.
I've then gone through and updated the code to handle this change.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* expprint.c (print_subexp_standard): Update to reflect changes to
enum range_type.
(dump_subexp_body_standard): Likewise.
* expression.h (enum range_type): Convert to a bit field enum, and
make the enum unsigned.
* f-exp.y (subrange): Update to reflect changes to enum
range_type.
* f-lang.c (value_f90_subarray): Likewise.
* parse.c (operator_length_standard): Likewise.
* rust-exp.y (rust_parser::convert_ast_to_expression): Likewise.
* rust-lang.c (rust_range): Likewise.
(rust_compute_range): Likewise.
(rust_subscript): Likewise.
The language_data type, from which language_defn inherits, is now
empty, and this commit removes it.
Each language is updated to no longer create and use a language_data
struct.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language_data): Delete.
(ada_language): Remove references to ada_language_data.
* c-lang.c (c_language_data): Delete.
(c_language): Remove references to c_language_data.
(cplus_language_data): Delete.
(cplus_language): Remove references to cplus_language_data.
(asm_language_data): Delete.
(asm_language): Remove references to asm_language_data.
(minimal_language_data): Delete.
(minimal_language): Remove references to minimal_language_data.
* d-lang.c (d_language_data): Delete.
(d_language): Remove references to d_language_data.
* f-lang.c (f_language_data): Delete.
(f_language): Remove references to f_language_data.
* go-lang.c (go_language_data): Delete.
(go_language): Remove references to go_language_data.
* language.c (unknown_language_data): Delete.
(unknown_language): Remove references to unknown_language_data.
(auto_language_data): Delete.
(auto_language): Remove references to auto_language_data.
* language.h (language_data): Delete struct.
(language_defn): No longer inherit from language_data.
* m2-lang.c (m2_language_data): Delete.
(m2_language): Remove references to m2_language_data.
* objc-lang.c (objc_language_data): Delete.
(objc_language): Remove references to objc_language_data.
* opencl-lang.c (opencl_language_data): Delete.
(opencl_language): Remove references to opencl_language_data.
* p-lang.c (pascal_language_data): Delete.
(pascal_language): Remove references to pascal_language_data.
* rust-lang.c (rust_language_data): Delete.
(rust_language): Remove references to rust_language_data.
