Fix #3892: preserve unsafe for pointer constructors#3893
Merged
siegfriedpammer merged 1 commit intoJul 20, 2026
Conversation
Object creation can require an unsafe context solely because the selected constructor has a pointer parameter. Apply the existing unsafe-signature check to object creation nodes so the emitted declaration remains compilable. Assisted-by: Copilot:gpt-5.6-sol:GitHub Copilot CLI Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 86d2918e-5a24-48b4-9a86-41d331ec3720
Member
|
Thank you for your contribution! |
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
2 participants
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.
Fixes #3892.
Problem
IntroduceUnsafeModifierdetects pointer parameters on ordinary invocation expressions, but noton object creation expressions.
If the constructor argument itself contains no pointer syntax, such as
new NativeBuffer(null),the required unsafe context is therefore lost. A field that originally had an
unsafemodifieris emitted without one, and the output fails to recompile with CS0214.
Solution
Apply the existing
HasUnsafeResolveResultcheck toObjectCreateExpression, matching thehandling already used for
InvocationExpression.This uses the selected constructor's resolved parameter types, so it remains general and does
not depend on a particular struct or argument shape.
Tests
Added a Pretty regression case where a static field constructs a value through a
void*constructor while passing
null.Validation:
UnsafeCodePretty matrix: 20 passedRelease solution build: 0 warnings, 0 errors
Full solution test suite: 4,885 passed, 15 existing skips
At least one test covering the code changed