enable c++20

[jungleraptor]

Adds a couple of functions that are essentially necessary to enable using libc++ and clang-15 with C++20

I tested locally on mac with clang-15 and libc++

[pcrumley]

Wait for @RReichert approval before merging plz

[RReichert]

Although the code works, I question if this is the best way forward. I would recommend something like this:

function(check_libcpp success)
  check_cxx_source_compiles("
    #include <iostream>
    int a =
    #ifdef _LIBCPP_VERSION
      1;
    #else
      kdfasfdl
    #endif
    int main() {
      return 0;
    }
  " ${success})
endfunction()

Where the function returns the true/false results. Its the responsibility of the caller to than add the definition to the compiler via target_compile_definitions. Using -D command line option is compiler specific way to add definitions, other compilers might not follow that approach (even though everything we support currently does).

I'd imagine that these checks would be used by one of the swift_add_* target functions to add the definitions to the source files, as PUBLIC definitions.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[jungleraptor]

Although the code works, I question if this is the best way forward. I would recommend something like this:

function(check_libcpp success)
  check_cxx_source_compiles("
    #include <iostream>
    int a =
    #ifdef _LIBCPP_VERSION
      1;
    #else
      kdfasfdl
    #endif
    int main() {
      return 0;
    }
  " ${success})
endfunction()

Where the function returns the true/false results. Its the responsibility of the caller to than add the definition to the compiler via target_compile_definitions. Using -D command line option is compiler specific way to add definitions, other compilers might not follow that approach (even though everything we support currently does).

That was mostly for readability - _LIBCPP_ENABLE_CXX20_REMOVED_FEATURES would also work fine with target_compile_definitions - I just thought that it would make what we're doing more obvious for a less cmake savvy future reader (cmake's syntax for setting a variable isn't exactly what I'd call expressive). I doubt that in practice we'd use this standard library with a non gcc/clang standard library.

I'd imagine that these checks would be used by one of the swift_add_* target functions to add the definitions to the source files, as PUBLIC definitions.

I agree with your overall point. It's not a good API - we're writing it to a specific implementation issue instead of providing an interface for the caller.

I've updated the functions to just be pass/fail and then the caller can figure out what to do with the result.