[SR-14507] Default argument generators should be part of ABI for Swift?

[johnno1962]

Previous ID	SR-14507
Radar	rdar://problem/76852457
Original Reporter	@johnno1962
Type	Bug
Status	Resolved
Resolution	Won't Do

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: 8a97fb438d86d022aa112624485f5953

Issue Description:

Hi Apple,

The symbols for default argument generators have been historically given "hidden" visibility, presumably as a way they don't get included in Swift's exported ABI even though in a real sense they are part of Swift's ABI that has to be kept stable. I made a PR mentioning this #33452 but it never received any visibility apart from a couple of drive by thumbs up.

This causes a problem for me trying to maintain a project for "hot reloading" Swift implementations as when a user updates a source file using a default argument to be reloaded using a .dylib it fails as "hidden" symbols are not available to the dynamic loader:

johnno1962/InjectionIII#201 (comment)

I have a work-around of sorts retrospectively patching object files to "unhide" these symbols but it would be better for users and in a sense more consistent if someday these symbols weren't emitted "hidden" by the compiler. I don't expect this to change but I'm raising an issue in the hope someone at least thinks about this.

[typesanitizer]

@swift-ci create

[typesanitizer]

I made a PR mentioning this #33452 but it never received any visibility apart from a couple of drive by thumbs up.

For this specific bit: we get a lot of PRs so the review process is decentralized. You'd want to ask someone for review to make sure your PR gets looked at. If you're not sure who to ask for review:

1. You can consults GitHub's suggested reviewers to ping someone/check git blame.
2. You could create a forum post under the development category to discuss the change and ask who would be a good person to review.

[jckarter]

The PublicNonABI is intentional. Default argument generators are not part of the ABI, they have purely compile-time effect, and a new SDK is allowed to change the default, or add defaults to existing arguments, without affecting ABI. If you want to "hot reload" a different default value, then you will need to put that default value behind a call into a function that is itself publicly visible and dynamically-replaceable, and hot-reload the implementation of that function.