Backporting changes from shish

[moufmouf]

This PR backports all changes made in the shish fork.

I guess a few things need to be changes before merging this (putting back the README in place would be change number 1). @shish would you be interested in being a contributor of the original repo? (instead of working on your own fork? This could avoid fragmentation :) )

[shish]

Yes I'm happy to help out here and avoid fragmentation :)

Another thing before merging is to decide which versions of PHP are supported - I forget the details and I'm currently AFK travelling for a couple of days so can't easily look it up, but IIRC I couldn't figure out a way to accurately implement wrappers for both PHP<8.2 and PHP>=8.2 at the same time (I think it was because 8.1 can't parse "true" as a return type and php8.2's standard library includes a function which uses "true" as a return type) - for my fork I decided to just support 8.2 onwards, but that is something that should be consciously decided by the maintainence team rather than accidentally happening in the middle of a giant merge

[staabm]

thx for working in all the upstream changes. I am not confident whether this huge PR should be merged.
I would love doing smaller PRs per change (I guess for most of the changes simple PRs are already open).

if the other maintainers think this PR here has no problems, I am fine with merging though

//cc @shish @OskarStark @silasjoisten

[shish]

My fork is basically upstream + having spent a few days manually merging most of the PRs and dealing with all the merge conflicts (and given how stale upstream had grown, there were a lot of merge conflicts, odds are that the merges weren't perfect...) - having extra eyes sounds like a good idea in any case

Another spanner in the works is that upsteam's build is so out of date that the CI and build process doesn't work until after most of those merges are done - so if you want to use the upstream code as a basis and then merge the outstanding PRs one at a time, be aware that it'll be hard to get any signal on if the individual merges are good or not ^^;;

[OskarStark]

I would also prefer smaller PRs.
About the PHP version, it seems legit to me, what @shish says about the return type. Can you please elaborate when you are back from traveling?

That said, I would be fine in dropping PHP 8.1 as there is a version for someone which can be used, so we can move one. Thoughts?

[shish]

If somebody else feels like taking the upstream code and merging most of the outstanding PRs, we can see if you get the same result that I got, which would be one way of validating our work, though it seems very labour intensive 😅

[staabm]

@shish I think I have now merged most changes, which were provided by pull requests to thecodingmachine/safe
could you double check whether there is nothing missing and also provide your manual changes as a PR from your fork?

does this sound feasible/useful?

[shish]

The PRs I've sent so far were mostly the infrastructure bits (CI/CD etc) as those were fairly simple to break out into smaller pieces - the changes to the generator itself are something I'm still figuring out how to split up ^^