-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rvalue reference, perfect forwarding and variadic template support #6
Conversation
If you could rebase this on the latest develop and resolve the merge conflict, then we'll get a CI build out of it. Thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see no tests added as part of these changes. Do you believe the standard set of tests using C++03 and C++11 modes with the pre-existing test code is sufficient? We'll see, once you rebase on master and get a CI build with code coverage.
7fc1b97
to
4a51439
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-5.0 cxxstd=11 fails, see:
https://api.travis-ci.org/v3/job/409990297/log.txt
6477743
to
abe71f8
Compare
Codecov Report
@@ Coverage Diff @@
## develop #6 +/- ##
===========================================
+ Coverage 76.53% 78.62% +2.08%
===========================================
Files 13 13
Lines 260 262 +2
Branches 55 55
===========================================
+ Hits 199 206 +7
+ Misses 10 5 -5
Partials 51 51
Continue to review full report at Codecov.
|
abe71f8
to
89b0a76
Compare
A long time since I created this pull request. |
The build failure is erroneous - everything passed. |
This PR breaks old GCC (<= 4.6) in C++11 mode. For example,
I don't think it's sensible to use C++11 with old GCC, but IMHO "just #including
to
|
This branch (L506 and L670)
needs to SFINAE out |
Forgot to say the above comments are about |
Right. @jeking3, consider expanding the platform coverage in your Travis scripts, as already mentioned in boostorg/function#21. For legacy libraries, you really need 4.4 and 4.6 jobs to catch pull requests that break them. In addition, for g++ 6 and above you want to test C++14 because that's their default and that's what everyone would be using. Your testing g++7 in 03/11 mode is decidedly suboptimal. The minimum coverage I like is f.ex. https://github.com/boostorg/parameter/blob/develop/.travis.yml - g++ 4.4, 4.6, 4.8 (default), 5, 6, 7, 8; clang with and without libc++, Mac. Some of these can in principle be dropped (you could f.ex. test g++5/6 with 11/14, 7 and 8 with 14/17) but the time saved is usually not worth the loss in coverage, unless the library tests take a really long time. For community-maintained libraries not breaking things that used to work is a priority. |
(And for g++ 7 and above, and for later libc++, you want to test C++17 because of standard library removals that may need addressing.) |
I'd like the CI builds not to be a full matrix test, because of a couple reasons:
On the mailing list I thought we had discussed not testing < gcc 4.8 any more, and that folks can happily use older versions of boost if they need to support older compilers or language levels. At some point the compatibility matrix is not sustainable. Any commercial entity would have dropped C++03 support on this project a long time ago due to maintenance costs. I think there is a balance that needs to be made. Each PR cycle cannot kick off 50 builds which take 10 minutes each. Were these failures identified in the matrix tests? How does one compare two matrix tests on a repo from different dates to see what the regressions are? Is there a tool that can do this, or is it always manual? These issues found need to be opened as new issues or as PRs. Commenting here has a chance of getting lost because the PR is merged. |
If you would rather break things that worked before, you are not a good fit for the CMT. This is not what the CMT is about. |
That's not my intention, however the CMT or any other group cannot reasonably support an ever-growing backwards compatibility matrix. There do have to be reasonable limits. I will look into beefing up the CI test matrix in the CMT repositories. |
@morinmorin isn't that what #20 was for? |
Yes, that patch contains a fix for issues with |
@pdimov check this out - it catches the issues described: https://travis-ci.org/jeking3/assign/builds/441266324 I'd like to make the Windows build better as well. |
Looks good, you have to use 98 for g++ 4.4 though, it doesn't yet have 03. :-) |
If you switch UBSAN to g++ 8, you'll cover that as well without spending another job. All the clangs seem to be using libstdc++ though. You need to have at least one on libc++, whether by adding a Mac job, or by using libc++ on one of the existing Linux ones. |
There are even more issues, like many of the clang jobs are still using clang-5. Still working on it... :) |
clang-5 is the default clang++ on Travis at the moment, so that's probably why. For a minimal matrix, having libc++ is more important for coverage than having many clang versions, so I usually go with one default clang and one clang++-libc++. It's not that earlier clangs don't have their oddities but most libraries don't encounter them. I sometimes add clang-3.4 because that's the default system clang on Trusty: https://github.com/boostorg/smart_ptr/blob/develop/.travis.yml#L130 but it's really not that critical. |
@morinmorin is the detection logic for the macro |
@pdimov have you seen anything like this before on osx jobs? Simple commands like "cd" are failing.
|
In some rare cases (mainly for oldish compilers), Boost.Config says FEATURE_XXX is implemented in the compiler even if the implementation is incomplete. This is the case for the variadic template feature on GCC 4.4–4.6. For advanced usage like our case, we should use
to detect unsupported compilers. |
@morinmorin Is there just one particular block that needs this treatment, or other files in this repo?
|
Fixing
compile fine. So I guess just one file needs the treatment (though I haven't looked into other files). That said, it might be better to define
and use that macro extensively in Boost.Assign. |
This change broke the Range tests by the way. https://travis-ci.org/boostorg/range/builds/441323699 |
Thanks I am working the issue and will roll out CI improvements as far and
wide as possible.
…On Sun, Oct 14, 2018, 5:45 PM Peter Dimov ***@***.***> wrote:
This change broke the Range tests by the way.
https://travis-ci.org/boostorg/range/builds/441323699
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ALOdbfdiHCAem1b0QR7VHt7xDCrt6-6Qks5uk7BngaJpZM4CfXrL>
.
|
Wow, this PR broke the following code on all platforms!
Don't worry, this is simply fixed by adding
to |
@morinmorin I included that in #27 |
The tests should be fixed to include the Assign header first, "per best practices." By the look of it, they did start out this way, but then someone added the detail/workaround.hpp include in front, defeating the purpose. |
Adds rvalue, perfect forwarding and variadic templates.
Variadic templates replaces boost.preprocessor (only for compilers with both rvalue and variadic templates support). This removes the max argument limitation (BOOST_ASSIGN_MAX_PARAMS).
A change was required in assign_decay (related to this boost::decay issue: https://svn.boost.org/trac/boost/ticket/7760).