Fix NullReferenceException in friendly overloads of COM methods with optional pointer parameters#1109
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Optional parameters cannot be expressed with the
refmodifier on COM methods in order to avoid a pointer type. Doing so disallows the possibility of passing in null. EvenUnsafe.NullRef<T>()does not work because the .NET interop layer throwsNullReferenceExceptionwhen that's done.Instead, we leave it as a pointer type.
An alternative to this may be to declare the parameter as an array that allows
nullor exactly 1 element. But the API wouldn't describe itself very well, and enforcement wouldn't exist, leading to possible runtime failures.Fixes #1081
AI generated summary
This pull request includes a significant number of changes to various files in the codebase. The most important changes include adding a new enum to categorize different elements being generated in
Generator.cs, modifying methods inGenerator.Com.csto generate appropriate type syntax based on the generating element, and adding a new test method inCOMTests.csto verify the declaration of COM methods.Main interface changes:
src/Microsoft.Windows.CsWin32/Generator.cs: Added an enum calledGeneratingElementto categorize different elements being generated and modified theGetNamespaceForPossiblyNestedTypemethod to include an additional parameter for theCreateParameterListmethod. [1] [2]src/Microsoft.Windows.CsWin32/Generator.Com.cs: Introduced changes to add new parameters to various methods for generating appropriate type syntax based on the generating element. [1] [2] [3] [4]test/Microsoft.Windows.CsWin32.Tests/COMTests.cs: Added a new test method to verify the declaration of COM methods that accept[Optional, In]parameters.Other important changes:
src/Microsoft.Windows.CsWin32/Generator.Constant.cs: Modified theCreateConstantmethod to include a new parameterforElementand modified theToTypeSyntaxmethod to include a new parameterGeneratingElement.Constant. [1] [2]src/Microsoft.Windows.CsWin32/Generator.Extern.cs: Added a new parameterforElementto theCreateParameterListmethod and theToTypeSyntaxmethod. [1] [2] [3]src/Microsoft.Windows.CsWin32/Generator.FriendlyOverloads.cs: Modified theCreateConstantmethod to add a new parameterforElementto theToTypeSyntaxmethod.src/Microsoft.Windows.CsWin32/Generator.Handle.cs: Added a new parameter to theToTypeSyntaxmethod and modified the code to pass a specific value based on the generating element. [1] [2] [3]Please note that due to the large number of changes and limited space, only a subset of the changes are listed here.