Vendor Bitcoin Core v22.1

[tcharding]

Run the vendoring script:

./contrib/vendor-bitcoin-core.sh v22.1

(Please note, the branch name is incorrect, .1 not .0)

[tcharding]

CI fail is: cargo:warning=depend/bitcoin/src/pubkey.h:16:20: fatal error: optional: No such file or directory. I don't know what is going on here, I did notice that

• The optioal header is used in the last release without an issue in various other files
• The pubkey.h file changes to use #include <optional> in Core 22.1

EDIT: I had previously written #include <optional.h> which is wrong (yes I am not a C++ developer :)

[apoelstra]

ACK 10ea770

[apoelstra]

Maybe we should try patching out that #include?

I suspect the s390x compiler is just broken/outdated in some subtle way.

[tcharding]

It seems unusual that this error just showed up, the optional header is used all over the place and the s390x build has always worked?

[apoelstra]

Yes, but if the explicit #include is new then maybe we are tripping over some weird path misconfiguration or something.

I think we should start by just removing the line and seeing if CI will pass. (This will break my local CI, but that's fine, we're just trying to experiment.)

[tcharding]

I didn't really get where you were coming from with removing the include line, I did it anyways and the C++ code does not build because that include is needed. Am I misunderstanding your suggestion?

[apoelstra]

Sometimes #includes aren't necessary (because the relevant files are transitively included somewhere else).

But ok, what if you change it from optional.h to just #include <optional>?

(I'm just guessing random stuff here, feel free to ignore me if it doesn't make sense.)

[tcharding]

I was wrong it never was, or is anywhere else in the depend/ directory, optional.h. Any other ideas, I'm happy to try them out.

[apoelstra]

optional.h is part of the STL since C++17.

But normally you include it as #include <optional> which does some different path resolution and something to do with namespaces or whatever. If you use optional.h this is the "C way" of doing it which you're Not Supposed To Do, presumably because it's too transparent or efficient.

[tcharding]

Yesterday I checked we were using C++ 17, I tried using experimental/optional, and I tried using/removing optional.h in various places. One anomaly I noticed was that there was a 5 in the path of an error I got /some/path/C++/5? But that doesn't explain why this failure shows up with the upgrade of the vendored code, optional (and optional.h) is used in a bunch of places in the current Core version?

[apoelstra]

So, because this is a build failure on a particular CI box and not a test failure, and because we have scripts that confirm we're vendoring the code correctly, maybe let's see if v23 works, and if so, we'll merge/release this and just add a warning in the CHANGELOG that we weren't able to test it on s390. And then move on to v23 and forget about it.

[tcharding]

Nice plan! I'm on it.

[apoelstra]

ACK 0050787