tests: ensure libcurl.def contains all exports

[vszakats]

Add test1279 to verify that libcurl.def lists all exported API
functions found in libcurl headers.

Also:

• extend test suite XML stdout tag with the loadfile attribute.

• fix tests/extern-scan.pl and test1135 to include websocket API.

• use all headers (sorted) in test1135 instead of a manual list.

• add options --sort, --heading= to tests/extern-scan.pl.

• add libcurl.def to the auto-labeler GHA task.

Follow-up to 2ebc74c

Closes #11570

[vszakats]

I'd preferred using tests/extern-scan.pl to extract the CURL_EXTERN list, but that script has extra bits in its output. Can those be deleted and the raw symbol names kept? It's also missing websockets.h.

[bagder]

Can those be deleted and the raw symbol names kept?

That seems reasonable. extern-scan.pl is (only) used by test 1135, so it's just a matter of making sure that is still happy.

[vszakats]

Updated the Perl script to use raw symbol names, added websockets functions, then reused it from the GHA task.

[bagder]

Hm, on second thoughts. Couldn't perhaps test 1135 get extended to do this check as well or something? It would be nice if we could detect this problem locally already when working on a new thing.

[vszakats]

Forgot about the local aspect, but indeed, this would be useful. I just have idea how to implement it there. Would need to sort results, insert EXPORTS on top and compare with the external file.

[vszakats]

Gave it a try, terrible Perl practices beware.

Having symbols sorted isn't strictly necessary (and might even be a bad thing if DLL users rely on export ordinals, though I don't think anyone would do that on Windows specifically). With extern-scan.pl the raw order is also stable (as long as the declarations in the headers are), so might as well drop it. Though I prefer to keep lists sorted if possible.

UPDATE: I've updated the logic to omit sorting, this allowed to integrate the libcurl.def check into existing test1135. But, I'm now wondering what the VMS / OS/400-related comment in test1135 means and whether we should move that comment to libcurl.def itself? I'm not sure how the existing solution would ensure that we always append new symbols to the end of the list. E.g. a new 'easy' API can only be added in the middle of the whole list, even if adding it as last inside easy.h. I must be missing something.

# The VMS and OS/400 builds extract the CURL_EXTERN protos and use in
# the build. We break binary compatibility by changing order. Only add
# new entries last or bump the SONAME.

[dfandrich]

On a related note, could this be used in a similar way to ensure the OS/400 curl.inc.in file isn't missing anything? Maybe not *anything* but at least the public functions?

[vszakats]

@dfandrich Seems doable, it'd need a parser that extracts those extern symbols from curl.inc.in. Then sort it, along with libcurl.def, then compare them. There still remains a lot of details that can go out of sync with curl headers.

There is also a gnv_libcurl_symbols.opt for VMS. Similar to libcurl.def, with (much) more boilerplate and a hand-crafted symbol order for compatibility. Also outdated.

[vszakats]

Settling on a version that keeps libcurl.def sorted and adds a separate test for it.

The next issue is that tests/extern-scan.pl needs a manually maintained list of libcurl headers. I might tackle that.

[bagder]

Wow, this was a cool idea. Me like!