Blacklist powerpc-unknown-linux-{gnu,musl} as having non-ignored GNU C ZSTs.

[anyska]

Ref #64259 (this is a simpler alternative to that). See also #64259 (comment).

[eddyb]

r? @nikomatsakis or @pnkfelix

[smaeul]

This does not close #64259, as it does not solve the original issue. I found the bug on powerpc-unknown-linux-musl, and I would like it to be fixed on that target. As I mentioned multiple times in comments on the other PR, the ABI is determined by the compiler, not by libc. At least on Linux, target_env only denotes the libc in use, so it is irrelevant to this issue.

A sparc64 port of musl is in progress, and this PR won't fix that target either.

So while this PR does slightly improve the situation, #64259 (or a rebased version of it) still needs to be open to fix the bug on non-glibc targets that use the same ABI: Linux/musl, NetBSD, and OpenBSD.

[nikomatsakis]

@smaeul would your preference be to close this PR in favor of #64259?

[eddyb]

For the record, this PR was updated to include powerpc-unknown-linux-musl.
@anyska could take out the "Closes #64259" from the description.

Also, it might be more productive to open an issue about generalizing our blacklisting here to include all affected targets (we need a predicate for "platform C compiler supports GNU extensions" which might be "everything except MSVC" for all supported targets).

We should probably also have linted against passing ZSTs by value, since AFAICT it's not even compatible between empty structs defined in C vs C++, and there may be other gotchas too.
The only common uses of by-value ZSTs in FFI should be returning () or !.
I know @joshtriplett brought up #ifdef'd out fields, but I wonder how many of those cases are by-value or by-pointer (as I recently realized on another issue most C APIs I've seen almost always put structs behind pointers).

Oh also do we even handle returning ZSTs correctly, on the affected platforms? (EDIT: oh, that's #65111 (comment))

[nikomatsakis]

The truth is I don't really feel like the right person to review this -- @eddyb maybe you?

[eddyb]

The truth is I don't really feel like the right person to review this -- @eddyb maybe you?

I suggested this approach, so I'd rather not unilaterally approve it, maybe @nagisa or @hanna-kruppe?

[smaeul]

Thanks for updating the PR to include -musl targets.

I'm fine with going with this PR, and closing #64259 in the process, as long as there is an issue (maybe #65111?) to track fixing it "for real" at some point.

[nagisa]

@bors r+

[bors]

📌 Commit 162d727 has been approved by nagisa

[nagisa]

Edited the original comment to remove Closes.

[bors]

⌛ Testing commit 162d727 with merge 4f0edbd...

[bors]

☀️ Test successful - checks-azure
Approved by: nagisa
Pushing 4f0edbd to master...