Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix (U)IntPtr construction #1861

Merged
merged 6 commits into from
Jul 11, 2022
Merged

Conversation

filmor
Copy link
Member

@filmor filmor commented Jul 8, 2022

What does this implement/fix? Explain your changes.

Allows creating an IntPtr from Python. This is currently impossible, because we rely on automatic conversion (as IntPtr is a primitive type) while we don't actually implement one for this type (rightly so!).

The relevant code section is:

if (type.IsPrimitive || type == typeof(string))
{
if (Runtime.PyTuple_Size(args) != 1)
{
Exceptions.SetError(Exceptions.TypeError, "no constructors match given arguments");
return default;
}
BorrowedReference op = Runtime.PyTuple_GetItem(args, 0);
if (!Converter.ToManaged(op, type, out var result, true))
{
return default;
}
return CLRObject.GetReference(result!, tp);
}

Does this close any currently open issues?

#1116

Any other comments?

...

Checklist

Check all those that are applicable and complete.

  • Make sure to include one or more tests for your change
  • If an enhancement PR, please create docs and at best an example
  • Ensure you have signed the .NET Foundation CLA
  • Add yourself to AUTHORS
  • Updated the CHANGELOG

@filmor filmor mentioned this pull request Jul 8, 2022
23 tasks
@filmor filmor changed the title Add unit tests for (U)IntPtr conversions Fix (U)IntPtr conversions Jul 8, 2022
@filmor filmor changed the title Fix (U)IntPtr conversions Fix (U)IntPtr construction Jul 8, 2022
@filmor filmor force-pushed the fix-intptr-conversion branch from 54e5a7d to 1c21526 Compare July 8, 2022 18:41
@filmor filmor requested a review from lostmsu July 9, 2022 14:05
@filmor filmor marked this pull request as ready for review July 9, 2022 14:05
@filmor
Copy link
Member Author

filmor commented Jul 9, 2022

I'm not entirely happy with this, yet. I think we might want to do the special-casing in ClassObject instead, like it's done for enums and bigints. Thoughts?

@lostmsu
Copy link
Member

lostmsu commented Jul 10, 2022

Re: IntPtr

Why can't we just treat IntPtr as non-primitive type? Then its constructor will be invoked by normal means.

@lostmsu
Copy link
Member

lostmsu commented Jul 10, 2022

Maybe we should have an explicit set of types for which this constructor masking behavior should be used, instead of relying on IsPrimitive which was created for a totally different purpose.

@filmor
Copy link
Member Author

filmor commented Jul 10, 2022

Re: IntPtr

Why can't we just treat IntPtr as non-primitive type? Then its constructor will be invoked by normal means.

Because then it's always default constructed, apparently calling a cobstructor on a primitive type after it has been created "uninitialised" is a no-op. I can check again, though I'm quite certain that that was among the first things I've tried.

@lostmsu
Copy link
Member

lostmsu commented Jul 11, 2022

apparently calling a cobstructor on a primitive type after it has been created "uninitialised" is a no-op

@filmor this would be highly problematic depending on what types this behavior applies to. If it is just IsPrimitive types, then we just need to adjust handling explicitly. However, if it is the case for any value types, we are in trouble.

UPD. Just checked rc2 for the record, values types in general seem fine: TimeSpan(3, 2, 1).ToString() prints '03:02:01'.

IntPtr gives "TypeError: No match found for given type params"

tests/test_conversion.py Outdated Show resolved Hide resolved
@filmor filmor force-pushed the fix-intptr-conversion branch 2 times, most recently from a6cdc35 to 43f748b Compare July 11, 2022 12:23
@filmor filmor force-pushed the fix-intptr-conversion branch from 43f748b to ae5e074 Compare July 11, 2022 12:30
@filmor filmor merged commit 332f8e7 into pythonnet:release Jul 11, 2022
@filmor filmor deleted the fix-intptr-conversion branch July 11, 2022 12:38
@lostmsu
Copy link
Member

lostmsu commented Jul 11, 2022

@filmor this PR was rushed. There are few artifacts of development left in the final code, the latest commits never reviewed, and the earliest not reviewed completely. This would be OK if there was no active response for a few days, but simply bypassing review on new code is not a good idea.

}
}

if (result == null && !Converter.ToManaged(op, type, out result, true))
Copy link
Member

@lostmsu lostmsu Jul 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need a test for IntPtr constructor call with this path (e.g. parameter is neither CLR object nor Python int)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you expect to happen? It fails to convert, this is essentially the "old" code path. I'll add the test, though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@filmor actually, nothing specific. Just want to ensure it does not error in a weird way and the error is actually helpful.

/// <param name="args">Constructor arguments</param>
private static NewReference NewPrimitive(BorrowedReference tp, BorrowedReference args, Type type)
{
// TODO: Handle IntPtr
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dead TODO?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, I'll remove it.

@filmor
Copy link
Member Author

filmor commented Jul 11, 2022

@filmor this PR was rushed. There are few artifacts of development left in the final code, the latest commits never reviewed, and the earliest not reviewed completely. This would be OK if there was no active response for a few days, but simply bypassing review on new code is not a good idea.

It might have been a bit rushed, but that was mostly because I wanted to tackle the other remaining issues (regressions from the constructor refactor) and get a new rc out soon for people to test with. This one would have actually bitten myself for a change if we had released this as stable. :)

@filmor filmor mentioned this pull request Sep 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants