boost [math] excessive warnings via [lexical_cast] from [date_time] (and others) for clang 3.4?
In the regression tables the following warnings are coming out of math config. I'm trying to understand what this means given that 1) the tests compile and execute fine, 2) the deadline is up, and 3) several of the cases are compiled in c++11 mode (is it pre conformance bc it's clang3.4?). I've seen this warning in other places that include lexical_cast as well. So sure I could go and define the macro to quiet this, but seems like that should be done closest to the source. In other words maybe math should only tell us that in headers that have a real issue? Or will this soon be a real issue? ../boost/math/tools/config.hpp:42:9: warning: CAUTION: One or more C++11 features were found to be unavailable [-W#pragma-messages] ../boost/math/tools/config.hpp:43:9: warning: CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021. [-W#pragma-messages] ../boost/math/tools/config.hpp:44:9: warning: CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message. [-W#pragma-messages] Full examples https://www.boost.org/development/tests/develop/developer/date_time.html https://www.boost.org/development/tests/develop/output/teeks99-dkr-dc3-4-98-...
On 24/03/2020 13:58, Jeff Garland via Boost wrote:
In the regression tables the following warnings are coming out of math config. I'm trying to understand what this means given that 1) the tests compile and execute fine, 2) the deadline is up, and 3) several of the cases are compiled in c++11 mode (is it pre conformance bc it's clang3.4?). I've seen this warning in other places that include lexical_cast as well. So sure I could go and define the macro to quiet this, but seems like that should be done closest to the source. In other words maybe math should only tell us that in headers that have a real issue? Or will this soon be a real issue?
Well it will be a real issue in a year from now when we being removing C++03 support - it may be that lexical_cast's dependencies have nothing that will actually break (but I would need to check that), or that as a temporary measure we could continue to support C++03 in selected sub-parts if there is real demand for it. Question: will anyone care about clang-3.4 a year from now given that we're currently on clang-9 ? John.
../boost/math/tools/config.hpp:42:9: warning: CAUTION: One or more C++11 features were found to be unavailable [-W#pragma-messages] ../boost/math/tools/config.hpp:43:9: warning: CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021. [-W#pragma-messages] ../boost/math/tools/config.hpp:44:9: warning: CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message. [-W#pragma-messages]
Full examples https://www.boost.org/development/tests/develop/developer/date_time.html https://www.boost.org/development/tests/develop/output/teeks99-dkr-dc3-4-98-...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Tue, 24 Mar 2020 at 10:26, John Maddock via Boost <boost@lists.boost.org> wrote:
Question: will anyone care about clang-3.4 a year from now given that we're currently on clang-9 ?
clang-10 is final soon. It's only relevant on linux (clang-cl only sort of works from 3.8 and upwards and IOS does its own thing anyway) and how many have 3.4 as the default? degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
Well it will be a real issue in a year from now when we being removing C++03 support - it may be that lexical_cast's dependencies have nothing that will actually break (but I would need to check that), or that as a
it's basically using it for floating point traits and functions like changesign. lexical_cast/detail/if_nan.hpp #include <boost/math/special_functions/sign.hpp> #include <boost/math/special_functions/fpclassify.hpp>
Question: will anyone care about clang-3.4 a year from now given that we're currently on clang-9 ?
I'd be fine if the answer is to drop really old compilers -- who makes that decision these days, the steering committee?
On 24/03/2020 17:32, Jeff Garland via Boost wrote:
Well it will be a real issue in a year from now when we being removing C++03 support - it may be that lexical_cast's dependencies have nothing that will actually break (but I would need to check that), or that as a
it's basically using it for floating point traits and functions like changesign.
lexical_cast/detail/if_nan.hpp #include <boost/math/special_functions/sign.hpp> #include <boost/math/special_functions/fpclassify.hpp> Nod. And there's nothing in there that requires anything other than C++03, so I could fix this up to not issue the warnings if that's really required.
Question: will anyone care about clang-3.4 a year from now given that we're currently on clang-9 ?
I'd be fine if the answer is to drop really old compilers -- who makes that decision these days, the steering committee?
Not sure, but there was a message thread a while back to the effect that dropping C++03 support was OK as long as there was 12 months of deprecation first. John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Tue, Mar 24, 2020 at 10:42 AM John Maddock via Boost < boost@lists.boost.org> wrote:
Nod. And there's nothing in there that requires anything other than C++03, so I could fix this up to not issue the warnings if that's really required.
It would be nice if it's not a big deal to do, as I expect lexical cast will continue to support c++03. And the warnings show up in date-time, icl and probably other libraries that have lexical cast -- or include date-time. But really, only if it's simple to do. Not sure, but there was a message thread a while back to the effect that
dropping C++03 support was OK as long as there was 12 months of deprecation first.
Which seems entirely reasonable given that 03 is really 98 so we are talking about 20 years... Jeff
Gesendet: Dienstag, 24. März 2020 um 18:41 Uhr Von: "John Maddock via Boost" <boost@lists.boost.org>
On 24/03/2020 17:32, Jeff Garland via Boost wrote:
Well it will be a real issue in a year from now when we being removing C++03 support - it may be that lexical_cast's dependencies have nothing that will actually break (but I would need to check that), or that as a
it's basically using it for floating point traits and functions like changesign.
lexical_cast/detail/if_nan.hpp #include <boost/math/special_functions/sign.hpp> #include <boost/math/special_functions/fpclassify.hpp> Nod. And there's nothing in there that requires anything other than C++03, so I could fix this up to not issue the warnings if that's really required.
There was talk / the suggestion to move some core parts to a separate library, also to avoid circular dependencies: https://github.com/boostorg/math/issues/151 That would also solve this problem as a side effect.
There was talk / the suggestion to move some core parts to a separate library, also to avoid circular dependencies: Yes, and it is a good idea, but probably too late for this release.
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Gesendet: Dienstag, 24. März 2020 um 17:25 Uhr Von: "John Maddock via Boost" <boost@lists.boost.org>
On 24/03/2020 13:58, Jeff Garland via Boost wrote:
In the regression tables the following warnings are coming out of math config. I'm trying to understand what this means given that 1) the tests compile and execute fine, 2) the deadline is up, and 3) several of the cases are compiled in c++11 mode (is it pre conformance bc it's clang3.4?). I've seen this warning in other places that include lexical_cast as well. So sure I could go and define the macro to quiet this, but seems like that should be done closest to the source. In other words maybe math should only tell us that in headers that have a real issue?
Can't speak for John, but personally I think that deciding for each header individually whether it might use c++11 features in a year doesn't make sense. In turn that would mean that everytime you want to use a c++11 feature in a header that didn't use one before, you need to wait for another year and you have to be super careful about which header includes which other header. Thats just a waste of time. Either deprecate c++03 for the whole library or not at all. That aside, what is the harm in simply defining the supression macro when compiling your tests with older compilers? I think the bigger question is: Will date_time continue to support c++03 when (some) of the libraries it currently depends on don't?
Or will this soon be a real issue?
Well it will be a real issue in a year from now when we being removing C++03 support
[...] Question: will anyone care about clang-3.4 a year from now given that we're currently on clang-9 ?
As degski mentioned, I doubt clang 3.4 was a particularly popular compiler to begin with, so the answer is probably no. Two suggestions: 1) As c++11 support is not a yes/no thing, could you perhaps specify which compiler versions you plan to support? E.g. gcc 4.8 was/is a pretty popular c++11 compiler but had a lot of conformance issues and libstdc++ was still missing a lot of things. So while probably no one cares about clang-3.4, gcc 4.8 support might be important. As always, not supporting X wouldn't mean it won't work, just that you might not test it and might not invest time to fix compatibility problems. 2) If I understand this correctly, c++03 support is just now going to be deprecated. Maybe this should not yet generate compile-time warnings as soon as a header is included but for now only during compilation of boost math sources, examples and unit tests themselves. The general warning could then be added in the next release. Of course in addtion to announcements here on the ML, in the release notes, the docs and maybe on reddit, twitter and/or slack. Best Mike
On Tue, 24 Mar 2020 at 12:18, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Mike wrote:
As degski mentioned, I doubt clang 3.4 was a particularly popular compiler to begin with, so the answer is probably no.
Clang 3.4 was the default Clang on Ubuntu Trusty.
And then there was Xenial and there after Bionic, and judging from the past release dates soon a new LTS release. In the meanwhile IBM acquired RedHat (and Fedora and CentOS) ... degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
degski wrote:
On Tue, 24 Mar 2020 at 12:18, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Mike wrote:
As degski mentioned, I doubt clang 3.4 was a particularly popular compiler to begin with, so the answer is probably no.
Clang 3.4 was the default Clang on Ubuntu Trusty.
And then there was Xenial and there after Bionic, and judging from the past release dates soon a new LTS release. In the meanwhile IBM acquired RedHat (and Fedora and CentOS) ...
Sure, I'm not saying it's relevant. But if you consider g++ 4.8 popular because it was default on Trusty, you can't consider Clang 3.4 not-popular because it was, too.
Gesendet: Dienstag, 24. März 2020 um 20:00 Uhr Von: "Peter Dimov via Boost" <boost@lists.boost.org>
degski wrote:
On Tue, 24 Mar 2020 at 12:18, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Mike wrote:
As degski mentioned, I doubt clang 3.4 was a particularly popular compiler to begin with, so the answer is probably no.
Clang 3.4 was the default Clang on Ubuntu Trusty.
And then there was Xenial and there after Bionic, and judging from the past release dates soon a new LTS release. In the meanwhile IBM acquired RedHat (and Fedora and CentOS) ...
Sure, I'm not saying it's relevant. But if you consider g++ 4.8 popular because it was default on Trusty, you can't consider Clang 3.4 not-popular because it was, too.
But clang isn't and wasn't the default compiler on ubuntu. Also, IIRC, when we used clang at all back then, we directly installed 3.5 anyway and generally, clang was much less popular back then and mostly used for experimental stuff.
clang-10 just got released, so soon, was really soon. degski On Tue, 24 Mar 2020 at 13:00, Peter Dimov via Boost <boost@lists.boost.org> wrote:
degski wrote:
On Tue, 24 Mar 2020 at 12:18, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Mike wrote:
As degski mentioned, I doubt clang 3.4 was a particularly popular compiler to begin with, so the answer is probably no.
Clang 3.4 was the default Clang on Ubuntu Trusty.
And then there was Xenial and there after Bionic, and judging from the past release dates soon a new LTS release. In the meanwhile IBM acquired RedHat (and Fedora and CentOS) ...
Sure, I'm not saying it's relevant. But if you consider g++ 4.8 popular because it was default on Trusty, you can't consider Clang 3.4 not-popular because it was, too.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
So it looks like a change in math got pushed to develop that fixed this up, thank you. Are we pushing it to master for 1.73? On Tue, Mar 24, 2020 at 4:16 PM degski via Boost <boost@lists.boost.org> wrote:
clang-10 just got released, so soon, was really soon.
degski
On Tue, 24 Mar 2020 at 13:00, Peter Dimov via Boost <boost@lists.boost.org
wrote:
degski wrote:
On Tue, 24 Mar 2020 at 12:18, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Mike wrote:
As degski mentioned, I doubt clang 3.4 was a particularly popular compiler to begin with, so the answer is probably no.
Clang 3.4 was the default Clang on Ubuntu Trusty.
And then there was Xenial and there after Bionic, and judging from the past release dates soon a new LTS release. In the meanwhile IBM acquired RedHat (and Fedora and CentOS) ...
Sure, I'm not saying it's relevant. But if you consider g++ 4.8 popular because it was default on Trusty, you can't consider Clang 3.4 not-popular because it was, too.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 08/04/2020 15:11, Jeff Garland via Boost wrote:
So it looks like a change in math got pushed to develop that fixed this up, thank you. Are we pushing it to master for 1.73?
I believe I already have, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Ok, it probably just hasn't made it's way thru the regression matrix yet. Thanks again. On Wed, Apr 8, 2020 at 8:17 AM John Maddock via Boost <boost@lists.boost.org> wrote:
On 08/04/2020 15:11, Jeff Garland via Boost wrote:
So it looks like a change in math got pushed to develop that fixed this up, thank you. Are we pushing it to master for 1.73?
I believe I already have, John.
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Mar 24, 2020 at 11:01 AM Mike via Boost <boost@lists.boost.org> wrote:
Can't speak for John, but personally I think that deciding for each header individually whether it might use c++11 features in a year doesn't make sense. In turn that would mean that everytime you want to use a c++11 feature in a header that didn't use one before, you need to wait for another year and you have to be super careful about which header includes which other header. Thats just a waste of time. Either deprecate c++03 for the whole library or not at all.
Boost libraries jump thru a tremendous number of hoops -- see the macro list in boost.config. For many things it's not to bad to support different configurations, although that's increasingly difficult. Obviously something in math makes them ready to move on from 03, but probably not for the functions here. John, who is responsible in part for config will certainly know. I guess the odd part for me is gcc and other clang compilers in 98 mode don't have the warning -- so there must be something unique about 3.x. And sure, I might jump on the band wagon to dump support for 98/03 in some future release. And, overall I'd like to reduce those dependencies anyway and newer standard libraries have facilities to help on that. That aside, what is the harm in simply defining the supression macro when
compiling your tests with older compilers? I think the bigger question is: Will date_time continue to support c++03 when (some) of the libraries it currently depends on don't?
The suppression macro would need to go into the header, but it wouldn't solve the issue for a lexical_cast user.
Jeff Garland wrote:
The suppression macro would need to go into the header, but it wouldn't solve the issue for a lexical_cast user.
The issue for the lexical_cast user is that his code will break when Math drops C++03 support, and the whole point of the message is to communicate this. The message is supposed to be verbose and annoying, because otherwise nobody will pay any attention to it. Sure, the user has no immediate recourse; he can only apply pressure on the lexical_cast maintainers to deal with it somehow. But again, if there's no message, nobody will care.
On 24/03/2020 19:06, Peter Dimov via Boost wrote:
Jeff Garland wrote:
The suppression macro would need to go into the header, but it wouldn't solve the issue for a lexical_cast user.
The issue for the lexical_cast user is that his code will break when Math drops C++03 support, and the whole point of the message is to communicate this.
The message is supposed to be verbose and annoying, because otherwise nobody will pay any attention to it. Sure, the user has no immediate recourse; he can only apply pressure on the lexical_cast maintainers to deal with it somehow. But again, if there's no message, nobody will care.
Haha, yes, that's basically why I made it so... annoying. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Tue, Mar 24, 2020 at 12:19 PM John Maddock via Boost < boost@lists.boost.org> wrote:
On 24/03/2020 19:06, Peter Dimov via Boost wrote:
Jeff Garland wrote:
The suppression macro would need to go into the header, but it wouldn't solve the issue for a lexical_cast user.
The issue for the lexical_cast user is that his code will break when Math drops C++03 support, and the whole point of the message is to communicate this.
Although I think we've determined that the functions involved won't be impacted -- so we're warning about a future non-event. Perhaps turning off the warning in lexical_cast is the correct option for 1.73 with a refactor (probably of math functions to core) for 1.74.
The message is supposed to be verbose and annoying, because otherwise nobody will pay any attention to it. Sure, the user has no immediate recourse; he can only apply pressure on the lexical_cast maintainers to deal with it somehow. But again, if there's no message, nobody will care.
Haha, yes, that's basically why I made it so... annoying.
Having the desired effect :) If it looked trivial and difficult to mess up I'd commit the pr to lexical_cast myself, no pressure required. But looking at the code it wasn't trivial and I can see why it was wise to depend on the expertise of boost.math instead of trying to re-invent.
Jeff
On Tue, 24 Mar 2020 at 13:06, Peter Dimov via Boost <boost@lists.boost.org> wrote:
The issue for the lexical_cast user is that his code will break when Math drops C++03 support, and the whole point of the message is to communicate this.
Another option would be to keep supporting boost::lexical_cast '03 for a while, and move to Boost.Spirit, which is miles better anyway. Then while at it, additionally adopt <charconv>. degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
Gesendet: Dienstag, 24. März 2020 um 19:32 Uhr Von: "Jeff Garland via Boost" <boost@lists.boost.org>
On Tue, Mar 24, 2020 at 11:01 AM Mike via Boost <boost@lists.boost.org> wrote:
That aside, what is the harm in simply defining the supression macro when compiling your tests with older compilers? I think the bigger question is: Will date_time continue to support c++03 when (some) of the libraries it currently depends on don't?
The suppression macro would need to go into the header
Not sure if that would be a good idea. Even if you are sure that your headers will still compile in c++03 in a year (either because they no longer include boost math headers at all - neither directly nor indirectly - or the specific headers remain compatible with 03). That macro will leak and suppress the warning along different include chainis, where the authors might not make give any such guarantees. Of course you could define and later restore the macro, but personally I think such suppression macros really belong on the command line of whoever is assembling the final binary. Best Mike
On Tue, Mar 24, 2020 at 1:46 PM Mike via Boost <boost@lists.boost.org> wrote:
Gesendet: Dienstag, 24. März 2020 um 19:32 Uhr Von: "Jeff Garland via Boost" <boost@lists.boost.org>
The suppression macro would need to go into the header
Not sure if that would be a good idea.
I'm not a fan of the approach either -- hence the email thread. Even if you are sure that your headers will still compile in c++03 in a
year
And again, to be clear, they compile cleanly on clang4+ and all variants of gcc now bc the boost math warning is only relevant to clang3.x.
(either because they no longer include boost math headers at all - neither directly nor indirectly - or the specific headers remain compatible with 03).
The irony here is that, if anything, I'd keep lexical_cast for 03 compatibility and use to_string or charconv to break the dependency on lexical_cast. Of course, those require facilities not in 03.
That macro will leak and suppress the warning along different include chainis, where the authors might not make give any such guarantees.
Of course you could define and later restore the macro, but personally I think such suppression macros really belong on the command line of whoever is assembling the final binary.
Yep, but keep in mind that if you're using 1.73 boost with clang3.x you'll have to actively suppress a warning about something that is a 'future
problem' -- that isn't really an issue with your code in any way. It's simply a decision, ultimately, that boost authors have made that is annoying. I mean we could have a warning like "dropping support for clang3.x after this release for the following libraries' which would be far more informative and actionable from the user point of view. I feel we can come up with a better path than having this warning. Jeff
participants (5)
-
degski -
Jeff Garland -
John Maddock -
Mike -
Peter Dimov