On 11/27/20 6:08 PM, Iain Sandoe wrote:
Jason Merrill <ja...@redhat.com> wrote:

On Mon, Nov 23, 2020 at 8:52 AM Iain Sandoe <i...@sandoe.co.uk> wrote:
Jason Merrill <ja...@redhat.com> wrote:

(NOTE: likewise,   ^~~ starting indent is below ‘int’ for a fixed spacing
font)

===

I’m inclined to think that the second is more useful,
but have patches for both,
which (or something else) do you prefer?

I agree that the second is preferable, thanks.  But let's not underline all of "int" there, just the caret is sufficient.  I'd also drop the mention of Obj-C++.

t.C:2:1: warning: attributes are not permitted in this position [-Wattributes]
    2 | __attribute__(())
      | ^~~~~~~~~~~~~
t.C:3:11: note: attributes may be inserted here
    3 | extern "C" int foo (void);
      |           ^

(the caret _is_ below the space)

(cool, I got to find out how to make a diagnostic point to the space between two tokens)

OK?
thanks
Iain

OK, thanks.

[PATCH] C++ : Adjust warning for misplaced attributes.

This removes the reference to Objective-C++ for the warning that
attributes may not be placed before linkage specifications.  It also
adds a note that they may be placed after that.

gcc/cp/ChangeLog:

* parser.c (cp_parser_declaration): Add a not about where
attributes may be placed.
---
gcc/cp/parser.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 7a83bf4a2a7..fe1dffc391f 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -13567,9 +13567,12 @@ cp_parser_declaration (cp_parser* parser, tree prefix_attrs)
  /* We might have already been here.  */
  if (!c_dialect_objc ())
    {
+     location_t where = get_finish (t2->location);
      warning_at (token1->location, OPT_Wattributes, "attributes are"
- " only permitted in this position for Objective-C++,"
- " ignored");
+ " not permitted in this position");
+     where = linemap_position_for_loc_and_offset (line_table,
+  where, 1);
+     inform (where, "attributes may be inserted here");
      attributes = NULL_TREE;
    }
  token1 = t1;
--
2.24.1



Reply via email to