[release/5.0] When marshalling a layout class, fall-back to dynamically marshalling the type if it doesn't match the static type in the signature. #50138
Conversation
… the type if it doesn't match the static type in the signature.
jeffschwMSFT
added
the
Servicing-consider
leecow
added
Servicing-approved
|
No merge until #50410 is fixed |
jkotas
added
the
NO-MERGE
|
@leecow we had approved this issue. Then in the time since a customer came back with an issue in master that applies to this change. We have updated the PR (the original intent of the change remains the same). I suggest that we consider this issue approved based on our original discussion. Though happy to bring it back if further discussion is warranted. |
|
@jkoritzinsky is this PR now in a mergeable state? |
|
Yes, this PR is in a mergable state. Just waiting on an updated code review @AaronRobinsonMSFT |
|
@Anipik once we have @AaronRobinsonMSFT cr, this pr will be ready for merge. We found an issue and have sense included an updated commit to address it. |
jeffschwMSFT
removed
the
NO-MERGE
|
@Anipik this pr is ready to merge. Thanks |
i will merge the pr after the ci is complete. |
* [release/5.0] Use adjusted parent layout size to handle a non-zero-sized class inheriting from a zero-sized class that inherits from another zero-sized class. Fixes handling of zero-sized parent types that have zero-sized parent types. * Revert "[release/5.0] When marshalling a layout class, fall-back to dynamically marshalling the type if it doesn't match the static type in the signature. (#50138)" (#50883) (#51021) This reverts commit b71bb59.
ghost
locked as resolved and limited conversation to collaborators
Port of #50137, #50655, and #50735 to release/5.0
When we switched the struct marshalling system to be IL based, we accidentally stopped checking if the passed in object matched the type in the signature in the "layout class" case (where we have a sequential or explicit layout
classtype). This causes failures to marshal the derived types correctly since only the base type ends up being marshalled.Customer Impact
Without this change, developers need to manually marshal their types. An internal team (Halo) has worked around this by manually marshalling their types, but would prefer to remove this workaround.
Regression?
This was a regression from .NET Core 3.1.
See #49857
Testing
Tests for both the fix and backwards compatibility are included with this change.
Risk
Medium. This change affects marshalling of layout classes.