diff options
author | Jakub Jelinek <jakub@redhat.com> | 2022-05-25 14:21:54 +0200 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2022-05-25 14:21:54 +0200 |
commit | 7a3ee77a2e33b8b8ad31aea27996ebe92a5c8d83 (patch) | |
tree | 605b310deb982f78fb3357e14585ed24b83c02d4 /libitm | |
parent | 329417d775102803e0321b95ba932a64870ba677 (diff) | |
download | gcc-7a3ee77a2e33b8b8ad31aea27996ebe92a5c8d83.zip gcc-7a3ee77a2e33b8b8ad31aea27996ebe92a5c8d83.tar.gz gcc-7a3ee77a2e33b8b8ad31aea27996ebe92a5c8d83.tar.bz2 |
c: Improve build_component_ref diagnostics [PR91134]
On the following testcase (the first dg-error line) we emit a weird
diagnostics and even fixit on pointerpointer->member
where pointerpointer is pointer to pointer to struct and we say
'pointerpointer' is a pointer; did you mean to use '->'?
The first part is indeed true, but suggesting -> when the code already
does use -> is confusing.
The following patch adjusts callers so that they tell it if it is from
. parsing or from -> parsing and in the latter case suggests to dereference
the left operand instead by adding (* before it and ) after it (before ->).
Or would a suggestion to add [0] before -> be better?
2022-05-25 Jakub Jelinek <jakub@redhat.com>
PR c/91134
gcc/c/
* c-tree.h (build_component_ref): Add ARROW_LOC location_t argument.
* c-typeck.cc (build_component_ref): Likewise. If DATUM is
INDIRECT_REF and ARROW_LOC isn't UNKNOWN_LOCATION, print a different
diagnostic and fixit hint if DATUM has pointer type.
* c-parser.cc (c_parser_postfix_expression,
c_parser_omp_variable_list): Adjust build_component_ref callers.
* gimple-parser.cc (c_parser_gimple_postfix_expression_after_primary):
Likewise.
gcc/objc/
* objc-act.cc (objc_build_component_ref): Adjust build_component_ref
caller.
gcc/testsuite/
* gcc.dg/pr91134.c: New test.
Diffstat (limited to 'libitm')
0 files changed, 0 insertions, 0 deletions