Add an "addressable for dependencies" flag to value witness flags.

[jckarter]

This may be useful for type layout of borrow fields in the future, should we decide that addressable-for-dependencies borrows should always be represented by a pointer. rdar://153650278

[jckarter]

@swift-ci Please test

[jckarter]

@swift-ci Please test

[jckarter]

@swift-ci Please test

[jckarter]

@swift-ci Please test

[jckarter]

@swift-ci Please smoke test Linux

[atrick]

LGTM

[rjmccall]

What's the story here for existing value witness tables?

[jckarter]

@swift-ci Please test Linux

[jckarter]

@rjmccall It seems to me that the borrow representation is likely to require new runtime support, so it's likely to be deployment target limited (though hopefully we can still support back deploying static uses that don't need runtime layout).

However, there should also at least be a limited universe of @frozen standard library and Apple framework types that were retroactively made addressable-for-dependencies, so I was thinking that if we did make the effort to back deploy dynamic borrow layout, we could bake in a list of those types to retroactively apply the flag to. (Though that wouldn't help for non-platform ABI-stable libraries; those would still need to recompile.)

[rjmccall]

@rjmccall It seems to me that the borrow representation is likely to require new runtime support, so it's likely to be deployment target limited (though hopefully we can still support back deploying static uses that don't need runtime layout).

However, there should also at least be a limited universe of @frozen standard library and Apple framework types that were retroactively made addressable-for-dependencies, so I was thinking that if we did make the effort to back deploy dynamic borrow layout, we could bake in a list of those types to retroactively apply the flag to. (Though that wouldn't help for non-platform ABI-stable libraries; those would still need to recompile.)

Is there any problem here for a new OS running existing binaries that haven't been recompiled with the new mode? Do we need a way to recognize that case?

[jckarter]

Is there any problem here for a new OS running existing binaries that haven't been recompiled with the new mode? Do we need a way to recognize that case?

@rjmccall Thinking about it for a couple hours… existing binaries wouldn't directly make use of new runtime features, but they could call in to the new OS's libraries, and the new OS could be using new language features that interpret this new bit. The setting of the bit could be different from what a new compiler would generate from the new type; however, code in the new OS can't possibly have static knowledge of the old binary it's running with, so it doesn't seem possible for there to be a static/dynamic layout disagreement. And since the old binary was built in a world where ~Escapable and lifetime dependencies weren't a thing, it shouldn't be possible for new code to return dependent values back to the old code.

So it seems like old binaries would be OK with a new OS, though I could be missing something. Do you have any counterexamples?

[rjmccall]

Alright. I have some concerns about that impact with existing non-OS libraries, but maybe we can address that with documentation. At any rate, I agree it's better to have this information than not.

The code that's here LGTM, but there's a runtime aspect of this that should at least be tested, and you need to make sure that the preset value witnesses in the runtime have the right values (and that we don't use them for types that disagree).

[jckarter]

I was hoping to tackle the runtime updates separately (and not for the 6.2 branch, since I wanted to minimize risk there). As long as we start emitting binaries so that the bit is set properly, it seems to me we should be able to update the runtime later.