Clean up comment in language.h
Checks
| Context |
Check |
Description |
| linaro-tcwg-bot/tcwg_gdb_build--master-arm |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_gdb_check--master-arm |
success
|
Test passed
|
| linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 |
success
|
Test passed
|
Commit Message
I noticed a comment in language.h that was partially obsolete. This
patch removes the obsolete bits and makes a small change to the rest.
---
gdb/language.h | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
base-commit: e3998113f9b66cbd0806424ac4700d2aaf8d0f77
Comments
On Wed, 8 Apr 2026 09:01:23 -0600
Tom Tromey <tromey@adacore.com> wrote:
> I noticed a comment in language.h that was partially obsolete. This
> patch removes the obsolete bits and makes a small change to the rest.
> ---
> gdb/language.h | 16 +++++-----------
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/gdb/language.h b/gdb/language.h
> index 67e6ac438b6..da903eb702d 100644
> --- a/gdb/language.h
> +++ b/gdb/language.h
> @@ -661,17 +661,11 @@ extern const struct language_defn *get_current_language ();
> always points to *some* valid struct; it can be used without checking
> it for validity.
>
> - The current language affects expression parsing and evaluation
> - (FIXME: it might be cleaner to make the evaluation-related stuff
> - separate exp_opcodes for each different set of semantics. We
> - should at least think this through more clearly with respect to
> - what happens if the language is changed between parsing and
> - evaluation) and printing of things like types and arrays. It does
> - *not* affect symbol-reading-- each source file in a symbol-file has
> - its own language and we should keep track of that regardless of the
> - language when symbols are read. If we want some manual setting for
> - the language of symbol files (e.g. detecting when ".c" files are
> - C++), it should be a separate setting from the current_language. */
> + The current language affects expression parsing and evaluation and
> + printing of things like types and values. It does *not* affect
> + symbol-reading -- each source file in a symbol-file has its own
> + language and we should keep track of that regardless of the
> + language when symbols are read. */
>
> #define current_language (get_current_language ())
>
>
> base-commit: e3998113f9b66cbd0806424ac4700d2aaf8d0f77
LGTM.
Approved-by: Kevin Buettner <kevinb@redhat.com>
@@ -661,17 +661,11 @@ extern const struct language_defn *get_current_language ();
always points to *some* valid struct; it can be used without checking
it for validity.
- The current language affects expression parsing and evaluation
- (FIXME: it might be cleaner to make the evaluation-related stuff
- separate exp_opcodes for each different set of semantics. We
- should at least think this through more clearly with respect to
- what happens if the language is changed between parsing and
- evaluation) and printing of things like types and arrays. It does
- *not* affect symbol-reading-- each source file in a symbol-file has
- its own language and we should keep track of that regardless of the
- language when symbols are read. If we want some manual setting for
- the language of symbol files (e.g. detecting when ".c" files are
- C++), it should be a separate setting from the current_language. */
+ The current language affects expression parsing and evaluation and
+ printing of things like types and values. It does *not* affect
+ symbol-reading -- each source file in a symbol-file has its own
+ language and we should keep track of that regardless of the
+ language when symbols are read. */
#define current_language (get_current_language ())