[Range] 1.68 master/beta MSVC compilation error with /fpermissive-
When compiling using /fpermissive- (enable strict conformance) I get the following compilation error: boost\boost\range\concepts.hpp(257): error C3646: 'n': unknown override specifier boost\boost\range\concepts.hpp(264): note: see reference to class template instantiation 'boost::range_detail::RandomAccessIteratorConcept<Iterator>' being compiled boost\libs\beast\include\boost\beast\core\string.hpp(87): note: see reference to class template instantiation 'boost::basic_string_view<char,std::char_traits<char>>' being compiled boost\boost\range\concepts.hpp(257): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int boost\boost\range\concepts.hpp(257): error C3646: 'n': unknown override specifier boost\boost\range\concepts.hpp(264): note: see reference to class template instantiation 'boost::range_detail::RandomAccessIteratorConcept<Iterator>' being compiled I'm using the tip of master, digest 000bd8507f8a17ada2c1fef19158e16cdeabd631 Thanks
See https://github.com/boostorg/range/issues/66 Am 11.07.2018 um 16:13 schrieb Vinnie Falco via Boost:
When compiling using /fpermissive- (enable strict conformance) I get the following compilation error:
boost\boost\range\concepts.hpp(257): error C3646: 'n': unknown override specifier boost\boost\range\concepts.hpp(264): note: see reference to class template instantiation 'boost::range_detail::RandomAccessIteratorConcept<Iterator>' being compiled boost\libs\beast\include\boost\beast\core\string.hpp(87): note: see reference to class template instantiation 'boost::basic_string_view<char,std::char_traits<char>>' being compiled boost\boost\range\concepts.hpp(257): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int boost\boost\range\concepts.hpp(257): error C3646: 'n': unknown override specifier boost\boost\range\concepts.hpp(264): note: see reference to class template instantiation 'boost::range_detail::RandomAccessIteratorConcept<Iterator>' being compiled
I'm using the tip of master, digest 000bd8507f8a17ada2c1fef19158e16cdeabd631
Thanks
On Wed, Jul 11, 2018 at 7:32 AM, Alexander Grund via Boost <boost@lists.boost.org> wrote:
Several libraries fail to build with /permissive-, I have generated a log of build output: <https://gist.github.com/vinniefalco/40b2e8e6a283377330258ce1e3281b6c> Thanks
On 11 July 2018 at 17:35, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
Several libraries fail to build with /permissive-, I have generated a log of build output:
<https://gist.github.com/vinniefalco/40b2e8e6a283377330258ce1e3281b6c>
This thread shows how and why it's important to get boost to build with Clang/LLVM (clang-cl), as VS is (still) a moving target and clang probably already has it right. By reporting those bugs MS (which it possibly is), you'll also be helping VS (and your-selves) forward. Trying to fix a build of Boost with a vaporware like VS 15.6.6 seems a waste of time and is highly irrelevant. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On Wed, Jul 11, 2018 at 7:49 AM, degski via Boost <boost@lists.boost.org> wrote:
This thread shows how and why it's important to get boost to build with Clang/LLVM (clang-cl), as VS is (still) a moving target and clang probably already has it right. By reporting those bugs MS (which it possibly is), you'll also be helping VS (and your-selves) forward. Trying to fix a build of Boost with a vaporware like VS 15.6.6 seems a waste of time and is highly irrelevant.
I couldn't disagree more (although, Boost should also be compiled with clang-cl if it is not discontinued). The latest Visual Studio is not vaporware it is a released, shipping product which many people use to accomplish real work. And in fact, I suspect that Visual Studio actually fixed a bug which is what is causing this new compilation error. The code in question which fails is: BOOST_DEDUCED_TYPENAME difference_type n; This, to my eye, should not compile as the code appears in a class template where difference_type is a nested type of the base class and should not be visible unqualified. The resulting errors appear in the log I linked. Changing that code to the following: BOOST_DEDUCED_TYPENAME BidirectionalIteratorConcept<Iterator>::difference_type n; resolves the error for _MSC_VER >= 1912
On 11 July 2018 at 17:56, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
I couldn't disagree more (although, Boost should also be compiled with clang-cl if it is not discontinued).
You, I surmise, are alluding to the indeed dis-continued (it is), ill-conceived idea of Clang/C2 (C2 is the VC backend)) as opposed to Clang/LLVM. MS, words from the mouth of STL (the man), is testing their STL (the library) with Clang/LLVM, Boost should do the same. MS is, from what I gather also a (one of the) contributors to Clang.
The latest Visual Studio is not vaporware it is a released, shipping product which many people use to accomplish real work.
Yes, it was, but even today I upgraded to 15.7.5, to which I only upgraded 2 weeks ago or so. Today's 15.7.5 is also 'a shipped release'. If one has any sense one pushes the button and get upgraded, particularly non-corporates will do that. And in fact, I suspect that Visual Studio
actually fixed a bug which is what is causing this new compilation error.
It's better to first find out if the code should compile in the first place by referencing it with the (compilation) result of a compiler that might not have that (possible) bug. This, to my eye, should not compile as the code appears in a class
template where difference_type is a nested type of the base class and should not be visible unqualified.
This proves my point, iff clang would say it's shite as well, you're 99.999% sure and you know what to do, using VS will, at this moment, not be conclusive in any way, shape or form (you're stabbing in the dark). degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On 11 July 2018 at 16:12, degski via Boost <boost@lists.boost.org> wrote:
On 11 July 2018 at 17:56, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
I couldn't disagree more (although, Boost should also be compiled with clang-cl if it is not discontinued).
You, I surmise, are alluding to the indeed dis-continued (it is), ill-conceived idea of Clang/C2 (C2 is the VC backend)) as opposed to Clang/LLVM. MS, words from the mouth of STL (the man), is testing their STL (the library) with Clang/LLVM, Boost should do the same. MS is, from what I gather also a (one of the) contributors to Clang.
clang-cl.exe is CL.EXE compatible driver from the LLVM/clang distribution for Windows. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
The fixes for this are contained in the develop branch and only need to be merged. And yes it (obviously) was a MSVC bug and it seems to be resolved now. PS: And yes MSVC is a moving target. But concluding that it should not be supported by boost would be short-sighted. There are just to many users of Boost with MSVC and they rely on Boost abstracting all those dirty details relating to compiler bugs away (as well as platform dependencies etc). Am 11.07.2018 um 16:56 schrieb Vinnie Falco via Boost:
On Wed, Jul 11, 2018 at 7:49 AM, degski via Boost <boost@lists.boost.org> wrote:
This thread shows how and why it's important to get boost to build with Clang/LLVM (clang-cl), as VS is (still) a moving target and clang probably already has it right. By reporting those bugs MS (which it possibly is), you'll also be helping VS (and your-selves) forward. Trying to fix a build of Boost with a vaporware like VS 15.6.6 seems a waste of time and is highly irrelevant. I couldn't disagree more (although, Boost should also be compiled with clang-cl if it is not discontinued). The latest Visual Studio is not vaporware it is a released, shipping product which many people use to accomplish real work. And in fact, I suspect that Visual Studio actually fixed a bug which is what is causing this new compilation error.
The code in question which fails is:
BOOST_DEDUCED_TYPENAME difference_type n;
This, to my eye, should not compile as the code appears in a class template where difference_type is a nested type of the base class and should not be visible unqualified. The resulting errors appear in the log I linked. Changing that code to the following:
BOOST_DEDUCED_TYPENAME BidirectionalIteratorConcept<Iterator>::difference_type n;
resolves the error for _MSC_VER >= 1912
On 11 July 2018 at 18:16, Alexander Grund via Boost <boost@lists.boost.org> wrote:
PS: And yes MSVC is a moving target. But concluding that it should not be supported by boost would be short-sighted.
It was also extremely short-lived (it therefor deserves short-sightedness). There are probably a s***-load of bugs (and different ones) in every micro release MS has done in this year, you just have not yet heard (and probably never will) of them. You'll get zero feedback/support from MS on any of the issues related to these old micro-releases. Do you really propose to put energy into that? This one turned out to be a bug apparently. Iff you'd report bugs on the latest release (in MS parlance (nowadays) that means preview versions, 15.8 P3), you'll be welcomed. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On Wed, Jul 11, 2018 at 8:16 AM, Alexander Grund via Boost < boost@lists.boost.org> wrote:
The fixes for this are contained in the develop branch and only need to be merged.
And yes it (obviously) was a MSVC bug and it seems to be resolved now.
PS: And yes MSVC is a moving target. But concluding that it should not be supported by boost would be short-sighted. There are just to many users of Boost with MSVC and they rely on Boost abstracting all those dirty details relating to compiler bugs away (as well as platform dependencies etc).
Yes, but at some point we have to ship a boost release. [ We've had this discussion many times in the past - "should we delay Boost 1.XX because VS XX.yy will be released next week", and we've pretty much always said - "Nope - we're shipping" ] Note that this is not a commentary on the current details - just a general observation. -- Marshall
On 12 July 2018 at 23:31, Marshall Clow via Boost <boost@lists.boost.org> wrote:
PS: And yes MSVC is a moving target. But concluding that it should not be supported by boost would be short-sighted. There are just to many users of Boost with MSVC and they rely on Boost abstracting all those dirty details relating to compiler bugs away (as well as platform dependencies etc).
Yes, but at some point we have to ship a boost release.
Exactly, it should certainly not be held up because a bug in some by now evaporized version of VC (and subsequently fixed in newer versions) "needs" fixing. My point was wholly different, though, stating that, iff clang-cl would be a build option on windows, it would be much easier to pin-point a problem to either the Boost code, or a transitional bug in VC. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
Yes, but at some point we have to ship a boost release.
[ We've had this discussion many times in the past - "should we delay Boost 1.XX because VS XX.yy will be released next week", and we've pretty much always said - "Nope - we're shipping" ]
Note that this is not a commentary on the current details - just a general observation. Completely agreed. But this does also highlight the importance of proper workarounds. The current thing is a great example: A workaround for a MSVC bug was included in the RC. However the code for that was invalid C++ and guarded by a `_MSVC >= xxxx` version macro. Hence a bug in MSVC was fixed by using another bug in MSVC with the assumption the latter will not be fixed (soon).
My point is: Even those workarounds should be expected to work in the future by using proper C++ (as far as possible) which now is the case (thanks for the ones working on that). I see that once a project switched to a Boost version they stay there for quite a while and for those this will be a huge problem (Please don't argue that they could simply update boost. Sometimes newer Boost have breaking changes/new bugs in other libraries that prevent this [Boost.Serialization e.g.]) Alex Grund
degski wrote:
This thread shows how and why it's important to get boost to build with Clang/LLVM (clang-cl),
FWIW, all my attempts to get Appveyor to build the tests for System with Clang have failed and I'm out of ideas. https://github.com/boostorg/system/commits/feature/clang-appveyor
On 11 July 2018 at 19:53, Peter Dimov via Boost <boost@lists.boost.org> wrote:
degski wrote:
This thread shows how and why it's important to get boost to build with
Clang/LLVM (clang-cl),
FWIW, all my attempts to get Appveyor to build the tests for System with Clang have failed and I'm out of ideas.
I gathered so much, could you, please, post what is, in your opinion, your best effort in this respect. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On Wed, Jul 11, 2018 at 7:32 AM, Alexander Grund via Boost <boost@lists.boost.org> wrote:
Looks like a fix is available in develop and just needs merging: <https://github.com/boostorg/range/issues/66#issuecomment-404205038> Thanks
participants (6)
-
Alexander Grund -
degski -
Marshall Clow -
Mateusz Loskot -
Peter Dimov -
Vinnie Falco