-
Notifications
You must be signed in to change notification settings - Fork 285
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
error: static_assert failed due to requirement '__is_cpp17_move_insertable<std::__1::allocator<FunctionParserBase<double>>, false>::value' "The specified type does not meet the requirements of Cpp17MoveInsertable" #2710
Comments
From a brief analysis, the line which triggers the error:
where
We have explicitly deleted the move assignment operator and move constructor for this class (see: contrib/fparser/fparser.hh)
so it does make sense to me that it would fail to meet the requirements of "Cpp17MoveInsertable", however what's not clear to me is why that's an issue... we are just calling I would be happy to patch 1.4.1 if a satisfactory resolution to this issue can be found, but I don't have ready access to either clang-11 or FreeBSD so I'm afraid I won't be able to do much testing myself. |
Please install clang-11 on the OS of your choice and you should be able to reproduce this problem. |
My apologies, but I vaguely recall getting a second-hand report of running into this problem months ago, and I hastily decided the solution must be "go find a better compiler" since obviously push_back() does a copy construction not a move construction ... but looking into it more deeply today it seems like the new clang++ behavior here is still standards-compliant. I think the most broadly-compatible easy fix is for us to turn that parsers vector into a vector of unique_ptr ... but I also don't have a system handy with more than clang-10 in the repos, and my last few times trying to build clang++ from scratch did not go well, so I'll have no good way to test the patch. |
Out of curiosity, I made a list of classes in libmesh with deleted move constructors. As I understand it, these classes do not satisfy the "MoveInsertable" requirements and therefore cannot be inserted into a std::vector with push_back():
It came back with the following classes where the move constructor is deleted because it is not (easily) possible to default:
And these in which the move constructor could probably be defaulted with a small amount of work:
So, I think we are for the most part OK, since those in the first list are not typically stored by value in vectors (although we store vectors of Elem pointers quite often). I may take a crack at fixing the last two at some point. |
The main reason behind this change is to make the class default move-constructible, which should theoretically allow it to be stored by value in a std::vector via push_back(). Refs libMesh#2710
* RBConstructionBase * RBParametrized * RBEIMConstruction In general we should not call clear() in any class destructor unless we need to manually clean up memory managed by that class. Instead, we should just let the member destructors do their thing. Refs libMesh#2710
This is an attempt to fix the issue raised in libMesh#2710. Since FunctionParserBase has a deleted move constructor, it is not considered to be MoveInsertable, which means it cannot be passed to std::vector::push_back() by value.
This is an attempt to fix the issue raised in libMesh#2710. Since FunctionParserBase has a deleted move constructor, it is not considered to be MoveInsertable, which means it cannot be passed to std::vector::push_back() by value. Adding a vector<unique_ptr> to the class means that it can no longer be default copy constructed. We had a unit test of this but, no actual uses within the library so hopefully it's OK to drop it.
1.6.0-rc1 release asserts with all clang versions: 8,9, 10, 11. |
8 through 10 too? Now that I might be able to replicate; thanks! |
Yes, 1.6.0-rc1 fails with more compilers. |
I don't see how this can be possible? MOOSE guys have been using these compilers, at least versions 8 and 9, and have not run into any issues as far as I know. Note also that the potential fix merged in #2720 is not in 1.6.0-rc1 yet. I felt we should wait to see if it would work before backporting it to any releases. |
1.6.0-rc1 fails too. |
@yurivict Can you let us know how libmesh is configured when it hits the static_assert? Maybe it's that you are using |
The log linked above has all command lines. |
It might be that the compiler defaults to -std=c++17. You need to set your level which you don't currently do, |
It's an IPv6 URL. |
Setting |
In
This directly causes the failure at Gcc doesn't catch basic modern C++ bugs any more. Please either remove the delete statements, or the push_back statement. |
Yes, I understand the problem and we have already patched it in master... if you can try master on your system that would be very helpful.
OK... well I click the link in my browser (Chrome) and it doesn't work. Is there something special I need to do to view IPv6 links? |
You obviously don't have IPv6. When I raised this issue with the people who support the servers they said that about everybody is supposed to have IPv6 addresses because they are the future. Personally, I view these links through the Tor network. Tor exit nodes usually are IPv6-enabled. |
I tried the latest revision 2873a0e and it still fails the same way. |
gcc-9 also fails to build rc1:
|
The code is different now (the vector stores unique_ptrs instead of objects) so while I believe it may still not be quite right, I don't think the error can be the same as it was before.
This is an error in the Tecplot contrib code that hasn't been updated in ages, probably best to just configure with |
rev. 2873a0e fails like this:
|
OK, I see, the issue is that we had the same type of code in both parsed_function.h and parsed_fem_function.h, and the fix in #2720 was only for the latter. I will go ahead and push the same fix for that one. |
This is similar to the change made in 783091b for ParsedFEMFunction. For a class to be pushed-back onto a vector, it must be MoveInsertable, which FunctionParserADBase is not. Refs libMesh#2710
The problem is fixed in rev. 746b489, thank you. |
OK, great, thanks for letting us know. |
Thanks for the constant feedback! I know debugging-via-chat is the most painful sort of debugging; I'm glad it worked out this time. Here's hoping that just backporting these fixes will be sufficient for the release too. |
Thanks for fixing it! |
The master hashes of the commits cherry-picked and squashed to create this commit: PR #2720 783091b PR #2731 b67b3e4 0a1dbe4 73d58f2 3a61395 a6f14fe 00cd55d 1310eac A similar "combined" commit should also be cherry-picked onto the 1.4.x and 1.5.x series and new patch-level releases should be made for them, since this is an issue which prevents certain compilers from being able to compile the library. Refs #2710
clang-11 fails to compile libmesh-1.4.1 on FreeBSD:
Log: http://beefy18.nyi.freebsd.org/data/head-amd64-default/p549079_s365919/logs/errors/libmesh-1.4.1_3.log (IPv6 URL)
The text was updated successfully, but these errors were encountered: