Martin Sebor <mse...@gmail.com> wrote:
On 5/25/21 8:01 AM, Iain Sandoe via Gcc-patches wrote:
Hi Martin
Martin Sebor via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
The attached patch replaces the uses of TREE_NO_WARNING in
the Objective-C front end.
<gcc-no-warning-objc.diff>
I’ve been gradually trying to improve/add locations in the ObjC stuff.
To that end, I wonder if it might be worth considering always supplying
the intended masked warning (rather than omitting this when the node
currently has no location). I guess that would mean that the
setter/getter
would need to determine if there was some suitable location (more work
but better abstraction).
This would mean that an improvement/addition to location would
automatically
gain the improvement in masked warnings.
This is not an objection (the patch is OK for ObjC as is) .. just a
question,
I'm not sure I understand correctly.
Let me try to clarify: The calls to the {get,set}_no_warning() with
no option introduced by the patch are of two kinds: one where
the intent is to query or suppress all warnings for an expression
(or a DECL, like a synthesized artificial temporary), and another
where it's not apparent from the code which warning is meant to
be queried or suppressed. I think all the ones in the ObjC front
end are of the latter sort. (None of these calls are due to
the location being unknown.)
OK, thanks - that clarifies (and is not particularly surprising, there is
plenty to do there).
With that, if you are suggesting to try to find the suitable option
to pass to the latter kind of calls above, I agree.
Something for me to look at when there’s time, then…
If you have
ideas for what those might be I can give them a try. Looking at
the ObjC suppression code again, all the set_no_warning() calls
with no option are for what looks like synthesized types, so
maybe that's a clue: could -Wunused be the warning we want to
suppress there?
… I’d not hazard a guess right now,
thanks for the clarification
Iain
