Update canTriviallyDeleteOSSAEndScopeInst and a related assertion

[meg-gupta]

A destroy_value of Optional.none can be deleted.

A move-only struct with deinit has a non trivial SILType but OwnershipKind::None, such values cannot be deleted.

[meg-gupta]

@swift-ci smoke test

[atrick]

I'm not opposed to this fix. I just want to make sure everyone understands that Ownership.none can never apply to a struct-with-deinit. Ownership.none literally means that the type is trivial on this path. Meaning we know there is no deinit on this path

[meg-gupta]

@atrick You are right. My observation was from the earlier @_moveOnly type attribute which used Ownership::None even in the presence of deinit.

[meg-gupta]

But we can't assume Ownership::None implies anymore because a ~Copyable struct without deinit has OwnershipKind::None and non-trivial SILType ?

[atrick]

But we can't assume Ownership::None implies anymore because a ~Copyable struct without deinit has OwnershipKind::None and non-trivial SILType ?

I'm not really sure what assumptions are currently being made in move-only passes. I think Ownership::None always implies that the value is trivial. Even though its type might conservatively report non-trivial. That's the assumption in all the code I've written.

In my mind, we would like BitwiseCopyable implies SILType.isTrivial implies Ownership::None. Right @nate-chandler?

The statement above

~Copyable struct without deinit has OwnershipKind::None and non-trivial SILType ?

is consistent with that model of increasing information as the trivial representation is lowered. I just have no idea what is accomplished by making "~Copyable struct without deinit" nontrivial at the type level but trivial at the ownership level. Ownership::None is just a way of saying that this particular value is known to be trivial.

[nate-chandler]

we would like BitwiseCopyable implies SILType.isTrivial

That's a goal, yes. See rdar://123661042 .

[meg-gupta]

I'm not opposed to this fix. I just want to make sure everyone understands that Ownership.none can never apply to a struct-with-deinit. Ownership.none literally means that the type is trivial on this path. Meaning we know there is no deinit on this path

@atrick I created #72160 to show we can have Ownership.none for a non-copyable struct.