Skip to content
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

Compilation failure of tests with C++20 standard (caused by change of u8 literals) #2413

Closed
3 tasks
stac47 opened this issue Oct 1, 2020 · 2 comments · Fixed by #2550
Closed
3 tasks

Compilation failure of tests with C++20 standard (caused by change of u8 literals) #2413

stac47 opened this issue Oct 1, 2020 · 2 comments · Fixed by #2550
Assignees
Labels
kind: bug release item: 🐛 bug fix solution: proposed fix a fix for the issue has been proposed and waits for confirmation

Comments

@stac47
Copy link
Contributor

stac47 commented Oct 1, 2020

Compiling tests with gcc and the -std flag set to gnu++20 or c++20, leads to compilation issues.

What is the issue you have?

More precisely, the u8"" literals have changed with the C++20 standard via P0482 in a non backward-compatible way char8_t is not the same as unsigned char.

When we compile the test suite of the project we get the following kind of errors with gcc:

In file included from json-3.9.1/test/thirdparty/doctest/doctest_compatibility.h:6,
                 from json-3.9.1/test/src/unit-class_parser.cpp:30:
json-3.9.1/test/thirdparty/doctest/doctest.h: In instantiation of 'doctest::detail::Result doctest::detail::Expression_lhs<L>::operator==(const R&) [with R = char8_t [5]; L = const std::__cxx11::basic_string<char>&]':
json-3.9.1/test/src/unit-class_parser.cpp:513:17:   required from here
json-3.9.1/test/thirdparty/doctest/doctest.h:1119:32: error: no match for 'operator==' (operand types are 'const std::__cxx11::basic_string<char>' and 'const char8_t [5]')
 1119 | #define DOCTEST_CMP_EQ(l, r) l == r
      |                                ^

This comes from the following type of line which is not correct now:

 CHECK(parser_helper("\"\\ud80c\\udc60\"").get<json::string_t>() == u8"\U00013060");

As there are many ways to cope with this in the code (for instance described here, I let the maintainers decide which one fits the best.

Please describe the steps to reproduce the issue.

Build it the standard way

mkdir -p _build
cd _build
cmake ..
make V=1 -j8

Relevant environment variables:

  • CXXFLAGS=' -std=gnu++20 -fno-working-directory -ggdb3'
  • LDFLAGS=' -fno-working-directory -ggdb3'

Can you provide a small but working code example?

We can warkaround the problem by disabling the char8_t support with the -fno-char8_t compiler option.

What is the expected behavior?

Compilation with no error

And what is the actual behavior instead?

See above.

Which compiler and operating system are you using?

  • Compiler: gcc 11 (developement version)
  • Operating system: GNU/Linux ubuntu 20.04

Which version of the library did you use?

  • [x ] latest release version 3.9.1
  • other release - please state the version: ___
  • the develop branch

If you experience a compilation error: can you compile and run the unit tests?

  • yes
  • [x ] no - please copy/paste the error message below
@stale
Copy link

stale bot commented Dec 25, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Dec 25, 2020
@nlohmann
Copy link
Owner

@stac47 Thanks for reporting. I did not test the library with C++20 so far. The issue should be fixed with #2550. Can you please check the latest develop branch?

@stale stale bot removed the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Dec 30, 2020
@nlohmann nlohmann added solution: proposed fix a fix for the issue has been proposed and waits for confirmation state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated and removed state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated labels Dec 30, 2020
@nlohmann nlohmann linked a pull request Dec 31, 2020 that will close this issue
1 task
@nlohmann nlohmann self-assigned this Dec 31, 2020
@nlohmann nlohmann added this to the Release 3.9.2 milestone Dec 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: bug release item: 🐛 bug fix solution: proposed fix a fix for the issue has been proposed and waits for confirmation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants