More TBD work #9983
More TBD work #9983
Conversation
|
@swift-ci Please smoke test |
1 similar comment
|
@swift-ci Please smoke test |
|
@swift-ci Please smoke test and merge |
| tryPush(getSetter()); | ||
| tryPush(getMaterializeForSetFunc()); | ||
|
|
||
| if (hasObservers()) { |
There was a problem hiding this comment.
Can observers and addressors ever be public?
There was a problem hiding this comment.
I don't know if it is correct for them to be public, but yes, it seems that addressors can currently: rdar://problem/32391290
There was a problem hiding this comment.
Observers cannot and never will be, addressors can and probably always are.
There was a problem hiding this comment.
Does this mean addressors are sometimes called directly, and not just via getter/setter/materializeForSet?
There was a problem hiding this comment.
Ah, maybe I'm wrong, but I thought so. @rjmccall?
| // Field are only direct if the class's internals are completely known. | ||
| auto isIndirect = !CD->hasFixedLayout(); | ||
| addSymbol(LinkEntity::forFieldOffset(var, isIndirect)); | ||
| // FIXME: a field only has one sort of offset, but it is moderately |
There was a problem hiding this comment.
Should we find a way to use IRGen type lowering from TBDGen?
There was a problem hiding this comment.
Yes, rdar://problem/32252689 .
|
@swift-ci Please smoke test |
|
I've updated this, and the last commit especially is ugly, maybe @slavapestov has some suggestions about manipulating the functions associated with a requirement abstract storage decl? |
|
@swift-ci Please smoke test |
It is semantically incorrect to miss a symbol, and just misleading to include an incorrect one in the TBD file (and, it would take a compiler bug to actually try to reference one from some downstream code), so it is better to err on the side of including extra symbols than missing some. For now, computing the actual directness of a field is difficult, so let's include both of them. Fixes rdar://problem/32253411 .
Fixes rdar://problem/32253697 .
Unlike some other vars, these members are not also listed at the top level, adjacent to the VarDecl.
…ls are public. Specifically, public superprotocols of non-public protocols have some weird handling in SILGen, so we reproduce this. Fixes rdar://problem/32254485 .
|
@swift-ci Please smoke test. |
This includes two somewhat debatable changes, both of which bias the generated TBD towards including extra symbols (i.e. ones that aren't public in the final library) instead of missing them. The logic is that extra symbols should not affect downstream users as much, whereas missing a symbol may cause linker errors.