How do we work around SR-15532?

Summary of SR-15532:

  • On Linux.
  • Swift >= 5.5
  • Public properties in Swift's extension of C structs such as in_addr cannot be used outside the module.

How do we work around it?
I have thought about that in my own way, but I have no idea to work around it (not to mention how to fix it).

You could possibly make a wrapper struct around the C struct that allows you to perform those actions. That’s probably the most Swift way of doing it (because it allows you to swift-ify the interface of the C struct too).

An alternative could be to make a case-less enum with static methods that perform actions on whatever instance of the C struct they are passed. This method would allow you to still store the C struct directly in your variables and then just use the utility enum to perform certain actions. Which isn’t a super elegant solution in my eyes, but it might be what you’re looking for.


Thank you for the advice.
IIUC, we have to give up extending directly C-structs in Swift to work around the bug, don’t we?

Yeah, that’s the approach I’d take :)

I suspect that importing the modules that export C-APIs such as Foundation causes this issue: SR-15586.
There may be some clues...

I'm not sure I understand. Is this a regression in the 5.5.x compiler that's being fixed somewhere by someone eventually or is it no longer supported and we need to workaround it forever? AFAIK all that worked fine in previous compiler versions.

I think it is definitely a bug/regression. I hope someone (or I) could fix it...
I've been poorly investigating the issue, but I don't have any clues why TypeChecker fails only on Linux so far.

I found the reason of this bug, but I don't know how to fix it.
So, I've created a new topic:

1 Like

CC @Joe_Groff

Thank you for noticing this thread.

BTW, according to CODE_OWNERS.TXT, @jrose is the owner of ClangImporter. Is it still so?

>< No, I’m afraid not. I thought I updated that when I left Apple, oops!

@jrose Thank you for replying to my abrupt question. :pray:

Anyway, I wonder why this bug has come to the surface since Swift >=5.5 albeit it seems that the fundamental design of ClangImporter did not change for these several years.