aboutsummaryrefslogtreecommitdiff
path: root/gdb/rust-parse.c
AgeCommit message (Collapse)AuthorFilesLines
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi1-1/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-01-28Use the new symbol domainsTom Tromey1-1/+1
This patch changes the DWARF reader to use the new symbol domains. It also adjusts many bits of associated code to adapt to this change. The non-DWARF readers are updated on a best-effort basis. This is somewhat simpler since most of them only support C and C++. I have no way to test a few of these. I went back and forth a few times on how to handle the "tag" situation. The basic problem is that C has a special namespace for tags, which is separate from the type namespace. Other languages don't do this. So, the question is, should a DW_TAG_structure_type end up in the tag domain, or the type domain, or should it be language-dependent? I settled on making it language-dependent using a thought experiment. Suppose there was a Rust compiler that only emitted nameless DW_TAG_structure_type objects, and specified all structure type names using DW_TAG_typedef. This DWARF would be correct, in that it faithfully represents the source language -- but would not work with a purely struct-domain implementation in gdb. Therefore gdb would be wrong. Now, this approach is a little tricky for C++, which uses tags but also enters a typedef for them. I notice that some other readers -- like stabsread -- actually emit a typedef symbol as well. And, I think this is a reasonable approach. It uses more memory, but it makes the internals simpler. However, DWARF never did this for whatever reason, and so in the interest of keeping the series slightly shorter, I've left some C++-specific hacks in place here. Note that this patch includes language_minimal as a language that uses tags. I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp, which doesn't specify the language for a type unit. Arguably this test case is wrong. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30164
2024-01-28Use domain_search_flags in lookup_symbol et alTom Tromey1-4/+4
This changes lookup_symbol and associated APIs to accept domain_search_flags rather than a domain_enum. Note that this introduces some new constants to Python and Guile. I chose to break out the documentation patch for this, because the internals here do not change until a later patch, and it seemed simpler to patch the docs just once, rather than twice.
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2023-11-29Use C++17 [[fallthrough]] attributeTom Tromey1-2/+2
This changes gdb to use the C++17 [[fallthrough]] attribute rather than special comments. This was mostly done by script, but I neglected a few spellings and so also fixed it up by hand. I suspect this fixes the bug mentioned below, by switching to a standard approach that, presumably, clang supports. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159 Approved-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-10-10gdb: remove target_gdbarchSimon Marchi1-2/+3
This function is just a wrapper around the current inferior's gdbarch. I find that having that wrapper just obscures where the arch is coming from, and that it's often used as "I don't know which arch to use so I'll use this magical target_gdbarch function that gets me an arch" when the arch should in fact come from something in the context (a thread, objfile, symbol, etc). I think that removing it and inlining `current_inferior ()->arch ()` everywhere will make it a bit clearer where that arch comes from and will trigger people into reflecting whether this is the right place to get the arch or not. Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-05-23Simplify parser_state constructorTom Tromey1-1/+1
This simplifies the parser_state constructor by having it accept a parser_flags parameter.
2023-05-17Special case "&str" in Rust parserTom Tromey1-0/+10
"&str" is an important type in Rust -- it's the type of string literals. However, the compiler puts it in the DWARF in a funny way. The slice itself is present and named "&str". However, the Rust parser doesn't look for types with names like this, but instead tries to construct them from components. In this case it tries to make a pointer-to-"str" -- but "str" isn't always available, and in any case that wouldn't yield the best result. This patch adds a special case for &str. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22251 Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-05-01Fix crash in Rust expression parserTom Tromey1-2/+2
A user found that an array expression with just a single value (like "[23]") caused the Rust expression parser to crash. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30410
2023-04-17Add 128-bit integer support to the Rust parserTom Tromey1-14/+23
This adds support for 128-bit integers to the Rust parser. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21185
2023-03-09gdb, gdbserver, gdbsupport: fix whitespace issuesSimon Marchi1-1/+1
Replace spaces with tabs in a bunch of places. Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0
2023-02-19Convert block_static_block and block_global_block to methodsTom Tromey1-1/+1
This converts block_static_block and block_global_block to be methods. This was mostly written by script. It was simpler to convert them at the same time because they're often used near each other.
2023-02-19Convert more block functions to methodsTom Tromey1-1/+1
This converts block_scope, block_set_scope, block_using, and block_set_using to be methods. These are all done at once to make it easier to also convert block_initialize_namespace at the same time. This was mostly written by script.
2023-02-19Don't allow NULL as an argument to block_scopeTom Tromey1-1/+3
block_scope has special behavior when the block is NULL. Remove this and patch up the callers instead.
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-12-12Another Rust operator precedence bugTom Tromey1-2/+8
My earlier patch to fix PR rust/29859 introduced a new operator precedence bug in the Rust parser. Assignment operators are right-associative in Rust. And, while this doesn't often matter, as Rust assignments always have the value (), still as a matter of principle we should get this correct. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29859
2022-12-06Fix operator precedence bug in Rust parserTom Tromey1-1/+1
PR rust/29859 points out an operator precedence bug in the Rust parser. This patch fixes it and adds a regression test.
2022-06-07[gdb/rust] Add missing _() for error callTom de Vries1-1/+1
In commit 1390b65a1b9 ("[gdb/rust] Fix literal truncation") I forgot to add _() around a string using in an error call. Fix this by adding the missing _(). Tested on x86_64-linux.
2022-06-04[gdb/rust] Fix literal truncationTom de Vries1-1/+4
Make sure we error out on overflow instead of truncating in all cases. I've used as overflow string: "Integer literal is too large", based on what I found at <rust-lang/rust>/src/test/ui/parser/int-literal-too-large-span.rs but perhaps someone has a better idea. Tested on x86_64-linux, with a build with --enable-targets=all.
2022-03-28Add Rust parser check for end of expressionTom Tromey1-1/+5
I noticed that "print 5," passed in Rust -- the parser wasn't checking that the entire input was used. This patch fixes the problem. This in turn pointed out another bug in the parser, namely that it didn't lex the next token after handling a string token. This is also fixed here.
2022-03-07Define HOST_UTF32 in charset.hTom Tromey1-8/+4
rust-parse.c has a #define for the host-specific UTF-32 charset name. A later patch needs the same thing, so this patch moves the definition to charset.h for easier reuse.
2022-02-06gdb: remove SYMBOL_TYPE macroSimon Marchi1-2/+2
Add a getter and a setter for a symbol's type. Remove the corresponding macro and adjust all callers. Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
2022-02-06gdb: remove SYMBOL_CLASS macro, add getterSimon Marchi1-2/+2
Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a
2022-02-06Allow non-ASCII characters in Rust identifiersTom Tromey1-18/+52
Rust 1.53 (quite a while ago now) ungated the support for non-ASCII identifiers. This didn't work in gdb. This is PR rust/20166. This patch fixes the problem by allowing non-ASCII characters to be considered as identifier components. It seemed simplest to just pass them through -- doing any extra checking didn't seem worthwhile. The new test also verifies that such characters are allowed in strings and character literals as well. The latter also required a bit of work in the lexer. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20166
2022-02-06Fix Rust parser bug with function fieldsTom Tromey1-1/+1
In Rust, 'obj.f()' is a method call -- but '(obj.f)()' is a call of a function-valued field 'f' in 'obj'. The Rust parser in gdb currently gets this wrong. This is PR rust/24082. The expression and Rust parser rewrites made this simple to fix -- simply wrapping a parenthesized expression in a new operation handles it. This patch has a slight hack because I didn't want to introduce a new exp_opcode enumeration constant just for this. IMO this doesn't matter, since we should work toward removing dependencies on these opcodes anyway; but let me know what you think of this. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24082
2022-01-18Move gdb_regex to gdbsupportTom Tromey1-1/+1
This moves the gdb_regex convenience class to gdbsupport.
2022-01-18Move gdb obstack code to gdbsupportTom Tromey1-1/+1
This moves the gdb-specific obstack code -- both extensions like obconcat and obstack_strdup, and things like auto_obstack -- to gdbsupport.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
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.
2021-12-08Use for-each more in gdbTom Tromey1-19/+13
There are some loops in gdb that use ARRAY_SIZE (or a wordier equivalent) to loop over a static array. This patch changes some of these to use foreach instead. Regression tested on x86-64 Fedora 34.
2021-10-19Fix Rust lex selftest when using libiconvTom Tromey1-3/+10
The Rust lex selftest fails on our Windows build. I tracked this down to a use of UTF-32 as a parameter to convert_between_encodings. Here, iconv_open succeeds, but the actual conversion of a tab character fails with EILSEQ. I suspect that "UTF-32" is being interpreted as big-endian, as changing the call to use "UTF-32LE" makes it work. This patch implements this fix.
2021-06-11Implement Rust raw identifiersTom Tromey1-6/+26
This patch implements Rust raw identifiers in the lexer in gdb. There was an earlier patch to do this, but the contributor didn't reply to my email asking whether he had sorted out his copyright assignment. This is relatively straightforward, but a small test suite addition was needd to ensure that the new test is skipped on older versions of rustc -- ones that predate the introduction of raw identifiers. gdb/ChangeLog 2021-06-11 Tom Tromey <tom@tromey.com> PR rust/23427 * rust-parse.c (rust_parser::lex_identifier): Handle raw identifiers. (rust_lex_tests): Add raw identifier tests. gdb/testsuite/ChangeLog 2021-06-11 Tom Tromey <tom@tromey.com> PR rust/23427 * lib/rust-support.exp (rust_compiler_version): New caching proc. * gdb.rust/rawids.exp: New file. * gdb.rust/rawids.rs: New file.
2021-04-22Improve code coverage of Rust testingTom Tromey1-8/+3
I enabled code coverage and ran the gdb test suite, and noticed that the new Rust parser was missing testing on a few lines that were easy to cover. This patch mostly adds tests for certain syntax errors; but this process also uncovered a couple of real bugs: I must have cut-and-pasted the 'sizeof' parsing code from some other code, because it is checking for KW_MUT (the old bison parser did not do this), and the array length check is actually impossible because a negative number like '-1' is parsed as two tokens. gdb/ChangeLog 2021-04-22 Tom Tromey <tom@tromey.com> * rust-parse.c (rust_parser::parse_sizeof): Remove KW_MUT code. (struct typed_val_int) <val>: Now ULONGEST. (rust_parser::parse_array_type): Remove negative check. (rust_lex_int_test): Change 'value' to ULONGEST. gdb/testsuite/ChangeLog 2021-04-22 Tom Tromey <tom@tromey.com> * gdb.rust/modules.exp: Add checks for syntax errors. * gdb.rust/expr.exp: Add checks for syntax errors. * gdb.rust/simple.exp: Add checks for syntax errors.
2021-04-16Rewrite the Rust expression parserTom Tromey1-0/+2351
The Rust expression parser was written to construct its own AST, then lower this to GDB expressions. I did this primarily because the old expressions were difficult to work with; after rewriting those, I realized I could remove the AST from the Rust parser. After looking at this, I realized it might be simpler to rewrite the parser. This patch reimplements it as a recursive-descent parser. I kept a fair amount of the existing code -- the lexer is pulled in nearly unchanged. There are several benefits to this approach: * The parser is shorter now (from 2882 LOC to 2351). * The parser is just ordinary C++ code that can be debugged in the usual way. * Memory management in the parser is now straightforward, as parsing methods simply return a unique pointer or vector. This required a couple of minor changes to the test suite, as some errors have changed. While this passes the tests, it's possible there are lurking bugs, particularly around error handling. gdb/ChangeLog 2021-04-16 Tom Tromey <tom@tromey.com> * rust-parse.c: New file. * rust-exp.y: Remove. * Makefile.in (COMMON_SFILES): Add rust-parse.c. (SFILES): Remove rust-exp.y. (YYFILES, local-maintainer-clean): Remove rust-exp.c. gdb/testsuite/ChangeLog 2021-04-16 Tom Tromey <tom@tromey.com> * gdb.rust/simple.exp: Change error text. * gdb.rust/expr.exp: Change error text.
generated by cgit v1.1 at 2024-07-23 03:16:10 +0000