[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [PATCH] Fixes for clang compilation

From: Greg Chicares
Subject: Re: [lmi] [PATCH] Fixes for clang compilation
Date: Fri, 7 Apr 2017 00:19:26 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0

On 2017-04-06 00:06, Vadim Zeitlin wrote:
>  I've realize that I've apparently completely forgotten to post 2 patches
> which are required to fix clang build that I did more than 2 weeks ago, so
> please find them attached.
>  The first one is similar to the other fixes after [[noreturn]] started to
> be used and just moves it to the function declaration as otherwise clang
> (correctly) complains about it being declared [[noreturn]] too late, e.g.
> alert_cli.cpp:99:3: error: function declared '[[noreturn]]' after its first 
> declaration
> [[noreturn]]
>   ^
> alert.hpp:177:6: note: declaration missing '[[noreturn]]' attribute is here
> void alarum_alert         (std::string const&);
>      ^

Applied. I added a further commit to remove that attribute from the other
definitions of the same function in other files.

>  The other one fixes a warning given by clang for the unused private
> fields. This one could be disabled instead of fixing it if there is some
> really good reason to keep these fields

Could we just disable the warnings instead? Does this patch work?

diff --git a/input_sequence_parser.cpp b/input_sequence_parser.cpp
index a66c1a5..0a5fe8d 100644
--- a/input_sequence_parser.cpp
+++ b/input_sequence_parser.cpp
@@ -50,6 +50,8 @@ SequenceParser::SequenceParser
     ,allowed_keywords_              (a_allowed_keywords)
     ,keywords_only_                 (a_keywords_only)
+    stifle_warning_for_unused_value(inforce_duration_);
+    stifle_warning_for_unused_value(effective_year_);
     diagnostic_messages_ = diagnostics_.str();

> or, on the contrary, extended in
> order to remove the SequenceParser ctor arguments corresponding to them,

But if we do that, then we should remove them from class InputSequence too,
and then from InputSequenceEntry, and from 'input_realization.cpp'...and
then we'd have to add them back in if we ever want to use them.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]