You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Explicitly asserting CodeExporter beliefs about specific types of DataContracts (#118616)
Fixes#78704.
CodeExporter was ported from NetFx code where `DataContract` and all its
various sub-types were all internally visible. Also being code from the
old world, it leveraged many beliefs that it assumed to be true based on
knowing what sub-type of DataContract was being worked with. Now that
this export code lives in a separate assembly and has minimal access to
the internals of `DataContract` and virtually no access to any of its
subtypes, it's time to start explicitly stating the things that
CodeExporter assumes to be true.
This pull request improves code safety and robustness in
`CodeExporter.cs` by adding `Debug.Assert` statements to validate key
assumptions about non-null values and object state throughout the
codebase. These assertions help catch errors earlier during development
and clarify expectations for future maintainers.
Assertions for required object state:
* Added `Debug.Assert` checks to ensure that `TypeDeclaration` and
`TypeReference` are non-null before using them in nested type
generation, class contract export, and serializable contract export.
[[1]](diffhunk://#diff-aed5d73b49483bcc99c574cae5c5e7635ba4dcb43fa6ecc1404e6d95e1a9feebL489-R490)
[[2]](diffhunk://#diff-aed5d73b49483bcc99c574cae5c5e7635ba4dcb43fa6ecc1404e6d95e1a9feebL505-R507)
[[3]](diffhunk://#diff-aed5d73b49483bcc99c574cae5c5e7635ba4dcb43fa6ecc1404e6d95e1a9feebL822-R829)
[[4]](diffhunk://#diff-aed5d73b49483bcc99c574cae5c5e7635ba4dcb43fa6ecc1404e6d95e1a9feebL1155-R1165)
- These asserts rely on the knowledge that class and collection data
contracts should always have TypeReference/Declarations - which will be
reflected in the "info" objects being worked with here. (Not all
sub-classes of DataContract do.)
* Added assertions to verify that `BaseContract` is not null for
`CollectionDataContract` and `EnumDataContract` scenarios, including
collection name checks and item contract usage.
[[1]](diffhunk://#diff-aed5d73b49483bcc99c574cae5c5e7635ba4dcb43fa6ecc1404e6d95e1a9feebR613)
[[2]](diffhunk://#diff-aed5d73b49483bcc99c574cae5c5e7635ba4dcb43fa6ecc1404e6d95e1a9feebR636)
[[3]](diffhunk://#diff-aed5d73b49483bcc99c574cae5c5e7635ba4dcb43fa6ecc1404e6d95e1a9feebR655)
[[4]](diffhunk://#diff-aed5d73b49483bcc99c574cae5c5e7635ba4dcb43fa6ecc1404e6d95e1a9feebR1078)
[[5]](diffhunk://#diff-aed5d73b49483bcc99c574cae5c5e7635ba4dcb43fa6ecc1404e6d95e1a9feebL1205-R1216)
- Again, knowing the specific sub-type of DataContract being worked with
here allows us to assert that a 'BaseContract' exists.
Validation of attribute and reference values:
* Added `Debug.Assert` to confirm assembly name is not null when
generating code attributes, and to ensure base type references and item
names are present when exporting collection data contracts.
[[1]](diffhunk://#diff-aed5d73b49483bcc99c574cae5c5e7635ba4dcb43fa6ecc1404e6d95e1a9feebL521-R525)
[[2]](diffhunk://#diff-aed5d73b49483bcc99c574cae5c5e7635ba4dcb43fa6ecc1404e6d95e1a9feebR1248-R1258)
These changes collectively make the code more defensive and easier to
debug by catching unexpected null values and invalid states early in the
development cycle.
---------
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
contractCodeDomInfo.TypeReference=newCodeTypeReference(containingContractCodeDomInfo.TypeReference!.BaseType+"+"+nestedTypeName);// Again, nested types by definition have containing types.
513
+
Debug.Assert(containingContractCodeDomInfo.TypeReference!=null,"Nested types have containing types by definition - types with reference");
Debug.Assert(assemblyName.Name!=null,$"Current executing assembly name is not expected to be null in {nameof(CodeExporter)}.{nameof(CreateTypeDeclaration)} scenario");
collectionContractAttribute.Arguments.Add(newCodeAttributeArgument(ImportGlobals.ItemNameProperty,newCodePrimitiveExpression(GetNameForAttribute(itemName!))));// ItemName is never null for Collection contracts.
1265
+
Debug.Assert(itemName!=null,"ItemName is never null for Collection contracts.");
0 commit comments