Add is and as support for std::expected (v2)

[bluetarpmedia]

• Update cpp2util.h to support is and as for std::expected
• Add new pure2-expected-is-as regression test

This replaces the original PR #954; I couldn't successfully rebase it onto the updated changes in main so I gave up and created a new PR!

CC @filipsajdak

EDIT - The macOS build job is a spurious failure (not found for compiler: 'clang++'). I'm not sure why this happens but I've seen it a few times now. I don't have permission to retry the job in this repo, but in my own fork I just retry the job and it succeeds.

EDIT 2 - See PR #972 for the spurious macOS job failure

[JohelEGP]

I think you may have accidentally moved the built-in as code section.

[filipsajdak]

@bluetarpmedia i will take a look after a decision on how to implement is and as functions. #701 (comment)

[bluetarpmedia]

I think you may have accidentally moved the built-in as code section.

Thanks, restored now!

[hsutter]

Sorry for the lag one this. I think this in in pri-5, at least in part because I'm not sure if this PR has fallen behind the other is/as cleanup that was merged this summer (my fault, sorry).

Do you want to refresh this PR and it might move to pri-3?

[hsutter]

Hi! Do you want to pursue this now?

Also as described in #1322, this didn't make release 0.8, so I will need a new one-time CLA that will cover all your future contributions. I've emailed you the new CLA, and one it's completed I can look at PRs.

[bluetarpmedia]

I've made a change to the CI run-tests.sh script to allow a compiler configuration to optionally exclude test files from running in that config.

This is because there are two macOS configurations which share the same expected results directory (to avoid duplication), since up to now their results have been identical.

However, I've added a new pure2-expected-is-as test which fails to compile on both compiler configs (which is correct, because they don't support std::expected), but they produce slightly different error diagnostics because of the different location of their standard libraries:

/Applications/Xcode_14.3.1.app/...etc.../MacOSX.sdk/usr/include/c++/v1/math.h:895:1: note: 'exp' declared here

and

/Library/Developer/...etc.../MacOSX13.sdk/usr/include/c++/v1/math.h:895:1: note: 'exp' declared here

One option would be to stop sharing the expected results directory, but that seemed wasteful since it's only 1 test file which produces a different result, and this test doesn't even compile (as expected). So it didn't seem necessary to me to verify the diagnostic since other compiler configs do that already.

However, please let me know if you prefer the duplication or a different solution instead of using this new filtering exclusion method.

FYI @jarzec

[bluetarpmedia]

There are 2 ubuntu jobs failing but I believe this is unrelated to this PR's changes.

I've seen this happen before with #1198

Here's the diff:

-mixed-bounds-safety-with-assert.cpp2(11) void print_subrange(const auto:129&, cpp2::impl::in<int>, cpp2::impl::in<int>) [with auto:129 = std::vector<int>; cpp2::impl::in<int> = const int]: Bounds safety violation
+mixed-bounds-safety-with-assert.cpp2(11) void print_subrange(const auto:130&, cpp2::impl::in<int>, cpp2::impl::in<int>) [with auto:130 = std::vector<int>; cpp2::impl::in<int> = const int]: Bounds safety violation

GCC generates some kind of counter for the auto parameters.

[hsutter]

Thanks!

I've checked self-build and the first part of regression tests (building the .cpp2 tests to .cpp) and so far so good. But there seem to be weirdnesses when I get this branch, including that the compiler-specific regression tests folders all seem to be empty. (I worked around that it doesn't have all the venv/ files checked in for docs earlier this year).

I'm thinking that it would be best to rebase this -- could you do that please?

[bluetarpmedia]

I'm thinking that it would be best to rebase this -- could you do that please?

Sure thing, I've rebased it now.

Not sure what was going on with those missing files you mentioned. If you still have problems maybe try deleting your local is-as-expected-v2 branch and then get a fresh checkout of it?

[jarzec]

I've made a change to the CI run-tests.sh script to allow a compiler configuration to optionally exclude test files from running in that config.

This is because there are two macOS configurations which share the same expected results directory (to avoid duplication), since up to now their results have been identical.

However, I've added a new pure2-expected-is-as test which fails to compile on both compiler configs (which is correct, because they don't support std::expected), but they produce slightly different error diagnostics because of the different location of their standard libraries:

/Applications/Xcode_14.3.1.app/...etc.../MacOSX.sdk/usr/include/c++/v1/math.h:895:1: note: 'exp' declared here

and

/Library/Developer/...etc.../MacOSX13.sdk/usr/include/c++/v1/math.h:895:1: note: 'exp' declared here

One option would be to stop sharing the expected results directory, but that seemed wasteful since it's only 1 test file which produces a different result, and this test doesn't even compile (as expected). So it didn't seem necessary to me to verify the diagnostic since other compiler configs do that already.

However, please let me know if you prefer the duplication or a different solution instead of using this new filtering exclusion method.

FYI @jarzec

In fact there is a way to ignore diff chunks with given patterns - git has an option for that and the scripts exposes that. This was used in the past for similar issues with MSVC.
On the other hand the Clang v15 used so far on MacOs 13 comes from Homebrew. I've been thinking for a while that given that the results from version 14 are identical to those from 15 the 15 has little added value and can be dropped altogether.
I've had a look and GitHub now provides MasOs 15 runners where Clang 16 is used by XCode. I seems to make more sense now to drop the v15 and add the "official" Apple v16 instead.
I will try to have a look at al that.

[jarzec]

There are 2 ubuntu jobs failing but I believe this is unrelated to this PR's changes.

I've seen this happen before with #1198

Here's the diff:

-mixed-bounds-safety-with-assert.cpp2(11) void print_subrange(const auto:129&, cpp2::impl::in<int>, cpp2::impl::in<int>) [with auto:129 = std::vector<int>; cpp2::impl::in<int> = const int]: Bounds safety violation
+mixed-bounds-safety-with-assert.cpp2(11) void print_subrange(const auto:130&, cpp2::impl::in<int>, cpp2::impl::in<int>) [with auto:130 = std::vector<int>; cpp2::impl::in<int> = const int]: Bounds safety violation

GCC generates some kind of counter for the auto parameters.

Given that you modified a header file all the test include I cam not surprised some internal numbering changed. I am no expert in in the internals of GCC, but I would say it is safe to accept those changes if the numbering is stable between runs.