Add the Uri\Rfc3986\Uri class to ext/uri without wither support

[kocsismate]

There are a few WIP parts but the PR can already be reviewed.

Relates to #14461 and https://wiki.php.net/rfc/url_parsing_api

[ndossche]

Cursory glance, I see there's some todos wrt memory management as well so maybe I'll wait a bit on that

[TimWolla]

Some first remarks from just looking at the diff on GitHub.

[TimWolla]

Something I'm only noticing now: I think this should rather be called ext/uri/parser_rfc3986.c and php_lexbor.c would be ext/uri/parser_whatwg.c. The php_uriparser.c name is confusing to me, because uriparser is an extremely generic term.

To give another comparison with ext/random, since it is architecturally similar: Each engine has its own engine_enginename.c file, e.g. engine_xoshiro256starstar.c.

[TimWolla]

And similarly the public symbols in the file should also be prefixed with php_uri_. Just uriparser_ can conflict with the uriparser library itself.

Here I would suggest php_uri_rfc3986_handler.

But I'm also happy to leave this to a follow-up to not introduce too much churn.

[kocsismate]

Yes, this and the file renaming is something that I'm happy to do after most parts are merged.

[kocsismate]

The following patch fixes the leaks / memory management for me:

@TimWolla Thanks for the patch, it's awesome! TBH I didn't even think about using the UriMakeOwnerA() function, because I wanted to avoid its performance penalty. But you are right, this is the right call, it simplifies the code so much. I love it!

[TimWolla]

@kocsismate When stack allocating the struct the code should become even simpler (and possibly faster, due to fewer pointer indirection).

[DanielEScherzer]

I have no further suggestions, but don't feel qualified to approve this

[TimWolla]

Looks mostly okay for an initial merge now. The additional clean-up can happen in a follow-up to move forward. The leak should be fixed, though.

[TimWolla]

I don't particularly like that you reordered these. It makes the diff hard to read.

[kocsismate]

Yes. I should have waited a little bit, sorry! A few methods had to be removed due to the added implementation aliases, and that was the point I think when I moved a few methods.

[TimWolla]

Similarly to the other remark about file naming and organization, it might make sense to move the PHP_METHOD implementations into the matching source file to keep php_uri.c slim.

[ndossche]

Besides the things that Tim said, here some small remarks

[TimWolla]

Some minor suggestions, but this is good to merge for me now. Anything else can be done in follow-ups.

[TimWolla]

Suggested change

	staticsize_tstr_to_int(constchar*str, size_tlen)
	{
	intresult=0;
	staticzend_longstr_to_int(constchar*str, size_tlen)
	{
	zend_longresult=0;

It's being stored in a zend_long, so should return a zend_long. But perhaps @nielsdos has other suggestions.

[ndossche]

No your suggestion is fine