Skip to content

Use C++17 #6749

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

Closed
wants to merge 7 commits into from
Closed

Use C++17 #6749

wants to merge 7 commits into from

Conversation

tautschnig
Copy link
Collaborator

@tautschnig tautschnig commented Mar 23, 2022

Use C++17 now that it has become a build requirement.

  • Each commit message has a non-empty body, explaining why the change was made.
  • Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
  • Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
  • My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • White-space or formatting changes outside the feature-related changed lines are in commits of their own.

@tautschnig tautschnig added the Version 6 Pull requests and issues requiring a major version bump label Mar 23, 2022
@tautschnig tautschnig self-assigned this Mar 23, 2022
@thomasspriggs
Copy link
Contributor

I am in favour of moving to C++17. This will allow us to remove the library code which has been back ported C++11, which will reduce the maintenance needed. It would also support using std::variant without having to add a back port of it.

@codecov
Copy link

codecov bot commented Mar 23, 2022

Codecov Report

Attention: 38 lines in your changes are missing coverage. Please review.

Comparison is base (a8de0b7) 79.10% compared to head (6b691bc) 79.07%.

❗ Current head 6b691bc differs from pull request most recent head 6e1615c. Consider uploading reports for the commit 6e1615c to get more accurate results

Files Patch % Lines
src/goto-cc/compile.cpp 62.50% 6 Missing ⚠️
src/goto-instrument/cover.cpp 80.00% 3 Missing ⚠️
src/util/source_location.cpp 50.00% 3 Missing ⚠️
jbmc/src/jbmc/jbmc_parse_options.cpp 66.66% 2 Missing ⚠️
src/analyses/invariant_propagation.cpp 0.00% 2 Missing ⚠️
src/goto-cc/as_mode.cpp 0.00% 2 Missing ⚠️
src/goto-cc/ld_mode.cpp 0.00% 2 Missing ⚠️
src/goto-cc/ms_cl_mode.cpp 0.00% 2 Missing ⚠️
src/goto-instrument/count_eloc.cpp 0.00% 2 Missing ⚠️
jbmc/src/java_bytecode/java_bytecode_language.h 0.00% 1 Missing ⚠️
... and 13 more
Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #6749      +/-   ##
===========================================
- Coverage    79.10%   79.07%   -0.03%     
===========================================
  Files         1699     1694       -5     
  Lines       196508   196276     -232     
===========================================
- Hits        155443   155204     -239     
- Misses       41065    41072       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@martin-cs martin-cs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In principle... OK. But:

  1. Are there any currently supported linux distros that don't have g++ --version >= 7.0? I don't think so but RedHat and derivatives do tend to ship surprisingly old versions of tools.
  2. I am not seeing any changes to the CI set up. Is that because all of the tested platforms are already using a suitable version?

@tautschnig tautschnig force-pushed the version-6/c++-17 branch 2 times, most recently from 5f00f86 to c4a7735 Compare March 24, 2022 01:08
@tautschnig
Copy link
Collaborator Author

In principle... OK. But:

1. Are there any currently supported linux distros that don't have `g++ --version >= 7.0`?  I don't think so but RedHat and derivatives do tend to ship surprisingly old versions of tools.

According to https://access.redhat.com/solutions/19458, only RHEL 8 has a version of GCC new enough to build current CBMC (which requires GCC 5), but then that new-enough version is GCC 8, so we should be fine. But perhaps @TGWDB has an idea whether there might be any other users who might be unable to use a new-enough version of GCC.

2. I am not seeing any changes to the CI set up.  Is that because all of the tested platforms are already using a suitable version?

That's correct, no changes needed.

@tautschnig
Copy link
Collaborator Author

I am in favour of moving to C++17. This will allow us to remove the library code which has been back ported C++11, which will reduce the maintenance needed. It would also support using std::variant without having to add a back port of it.

Feel free to create a PR against my branch so as to introduce the use of std::variant: I've now added a bunch of commits that make good use of C++17, mostly by removing code.

@tautschnig tautschnig force-pushed the version-6/c++-17 branch 4 times, most recently from 47b6b33 to 9ba2012 Compare March 24, 2022 03:12
@TGWDB
Copy link
Contributor

TGWDB commented Mar 24, 2022

According to https://access.redhat.com/solutions/19458, only RHEL 8 has a version of GCC new enough to build current CBMC (which requires GCC 5), but then that new-enough version is GCC 8, so we should be fine. But perhaps @TGWDB has an idea whether there might be any other users who might be unable to use a new-enough version of GCC.

I'm not aware of Linux users who might have issues, but we need to make sure MSVC builds work. I believe as long as we have support for MSVC 2019 (currently tested in CI) we are ok.

@tautschnig tautschnig force-pushed the version-6/c++-17 branch 9 times, most recently from b03ffdb to 7ad368d Compare March 25, 2022 19:29
@tautschnig tautschnig changed the title Build using C++17 Build using C++17 [depends-on: #6753, #6754, #6755, #6756, #6764, #6767] Mar 25, 2022
kroening added a commit that referenced this pull request Mar 26, 2022
Add missing <functional> include [blocks: #6749]
@tautschnig tautschnig changed the title Build using C++17 [depends-on: #6753, #6754, #6755, #6756, #6764, #6767] Build using C++17 [depends-on: #6753, #6754, #6755, #6756, #6767] Mar 26, 2022
tautschnig added a commit that referenced this pull request Mar 29, 2022
CMake/macOS: upgrade minimum version to 10.15 [blocks: #6749]
@tautschnig tautschnig mentioned this pull request Apr 26, 2022
4 tasks
tautschnig added a commit that referenced this pull request May 10, 2022
goto_rw/range_spect: wrap in a class instead of using just a typedef [blocks: #6749, #6768]
tautschnig added a commit that referenced this pull request May 17, 2022
Disambiguate overloaded insert(...) calls [blocks: #6749]
tautschnig added a commit that referenced this pull request May 27, 2022
Remove unqualified use of nullopt [blocks: #6749]
@tautschnig tautschnig mentioned this pull request Sep 30, 2022
4 tasks
@tautschnig tautschnig changed the title Build using C++17 [depends-on: #6753, #6754, #6755, #6756] Build using C++17 [depends-on: #6754] Nov 9, 2022
tautschnig added a commit that referenced this pull request Dec 1, 2022
Replace assert(...) by macros from invariant.h [blocks: #6749]
@esteffin
Copy link
Contributor

esteffin commented Nov 8, 2023

As already agreed this now depends on #7989

@tautschnig tautschnig changed the title Build using C++17 [depends-on: #6754] Build using C++17 Nov 13, 2023
@tautschnig tautschnig changed the title Build using C++17 Use C++17 Nov 13, 2023
@tautschnig tautschnig force-pushed the version-6/c++-17 branch 2 times, most recently from b1f2826 to 6b691bc Compare November 14, 2023 11:46
Removes third-party code that is no longer necessary now that we use C++
17 as build standard. Future uses of optionalt should instead use
std::optional directly.
With the move to C++ 17 we can use std::make_unique instead.
With the move to C++ 17 we can use std::void_t instead.
With C++ 17 we can use the STL-provided implementation instead of
rolling our own (platform-dependent) code.
Python warns about the use of `\d`: we should use raw strings here as
that's not meant to be an escape sequence.
See
https://github.com/diffblue/cbmc/actions/runs/6856483568/job/18643716705?pr=6749
for one example of the failure: cargo-induced clang runs (via the cc
crate) weren't finding the C++ library (which ought to be libc++ and not
libstdc++ on this MacOS target). This appears to be caused by the
minimum build target being too low (where the cc crate is the one
setting that minimum). Override that by setting an environment variable.
See
https://github.com/rust-lang/cc-rs/blob/2d6a3b2119cf5eacc01e1f2877e064a7aede7819/src/lib.rs#L3497C52-L3497C76
for the Rust code implementing the logic.
The prefix lookup resulted in picking up the Release-Glucose cache from
check-macos-12-cmake-clang. This cache, however, was established with
Glucose as a SAT solver, which implies different compiler
command lines. Consequently, there would be 0 cache hits.
@tautschnig
Copy link
Collaborator Author

Closing as all commits have been moved into PRs of their own (#8028, #8031, #8032, #8033, #8034).

@tautschnig tautschnig closed this Nov 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Version 6 Pull requests and issues requiring a major version bump
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

5 participants