GCC 8.3 workaround

[nx10]

Compilation with GCC 8.1 - 8.3 is failing due to a compiler bug. I spent some time confirming which GCC versions are affected and it seems to be fixed in in GCC 8.4 (also fixed with GCC 9.1). (Compiler explorer: https://godbolt.org/z/beWsMznd5)

Issues referencing this problem:

• amalgamate/crow_all.h:9551:14: internal compiler error: in write_expression, with gcc 7.3 on Fedora 28 ipkn/crow#303
• Build is broken on gcc 8.3.0  ipkn/crow#345
• Example build issue #98
• Build failiing o Arch Linux moneroexamples/onion-monero-blockchain-explorer#120

This PR applies the workaround suggested in ipkn/crow#303 (comment) if one of the affected GCC versions is used. It also throws a preprocessor warning with instructions to upgrade either GCC version or C++ standard if it can not be applied.

I am not sure this workaround is in the support scope for this project, so it is fine for me if it is rejected. (It might still be helpful to stay open indefinitely for somebody who has to support GCC 8 < 8.4)

[The-EDev]

Thanks a lot for the work and comprehensive PR description.

I have 2 concerns (or suggestions) however, the first being the fact that you're immediately checking the value of __GNUC__, and while it will most likely not cause issues, it might be best to check if it was defined like the case with _MSVC_LANG or _MSC_VER.
The second is that we're issuing a warning that the compilation will fail, why not just use #error instead?

When it comes to the support scope of the project, we started development with support for newer and older Boost versions, the library has a workaround for Visual Studio 13 (I believe). And we recently added C++20 support (in the sense that the program will compile out of the box). So as long as the change won't require too much expansion in the future, I don't see a reason not to integrate it.

Thanks again for your work and please let me know when the PR is ready for review. Tests are already passing and as far as I can tell there aren't any formatting errors.

[nx10]

Thank you for your quick response.

I agree with and have added your suggestions.
The PR is now ready for review.

[The-EDev]

Testing it out in godbolt, I'm getting the following error when using gcc 8.1 and -std=c++14:

crow_all.h:11150:105: error: 'route' function with trailing return type has 'auto&' as its type rather than plain 'auto'

The problem seems to be that & would have to be part of the trailing return type, is the & necessary?

Everything else seems to be working fine (including the #error)

[The-EDev]

Will merge once the tests are done