Skip to content

Conversation

@john-h-k
Copy link
Contributor

Implements https://github.com/dotnet/corefx/issues/20256

Delegates all implementations to [U]Int32/[U]Int64. Uses InvariantCulture for ToString to maintain backcompat for the old ToString() method

@tannergooding
Copy link
Member

CC. @cston, @333fred

Copy link
Member

@tannergooding tannergooding Nov 26, 2019

Choose a reason for hiding this comment

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

nit: I think the convention is to do ((nint)_value) rather than ((nint)this)

Copy link
Member

Choose a reason for hiding this comment

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

Do both forms generate same IL? We should make sure that the native code generated for these is good.

Copy link
Member

@tannergooding tannergooding Nov 26, 2019

Choose a reason for hiding this comment

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

@john-h-k, could you get an assembly diff for the two forms?

I would hope the JIT folds them the same, but the latter ends up going through the explicit conversion API (vs directly converting the field).

We were already using the former for existing APIs (like ToString()).

@tannergooding
Copy link
Member

The reference assembly also needs to be updated and tests added, but I don't believe we can do it in the same PR until after #92 is merged.

Copy link
Member

@jkotas jkotas Nov 26, 2019

Choose a reason for hiding this comment

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

There are number of places throughout CoreLib that assume IntPtr/UIntPtr are not comparable. We should fix them up as appropriate.

For example,

// IntPtr/UIntPtr does not implement IComparable
should be fixed up.

Copy link
Member

Choose a reason for hiding this comment

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

@jkotas, do we have a rough list of these places?

It looks like 2 places in System.Array and no others for ELEMENT_TYPE_I or ELEMENT_TYPE_U (in managed code, I didn't check native):

I did a quick scan of some other places and didn't spot anything that was keying off typeof(IntPtr or typeof(UIntPtr). Most places look to just key off x is IComparable.

@danmoseley
Copy link
Member

@tannergooding what is next here? Are you waiting on the assembly diff mentioned above? Or is this ready for re-review?

@jkotas
Copy link
Member

jkotas commented Feb 3, 2020

This PR needs:

@tannergooding
Copy link
Member

It is waiting on the assembly diffs and the remaining feedback from Jan to be addressed. @john-h-k, please let us know if you need any assistance in getting this completed or if you have any questions.

Copy link
Member

@tannergooding tannergooding left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks for working through this and getting it done @john-h-k

@tannergooding
Copy link
Member

@jkotas, would you be able to give this a quick review? It would be nice to get this in before the snap today so it can make the same preview as the compiler support for nint/nuint.

Copy link
Member

@jkotas jkotas left a comment

Choose a reason for hiding this comment

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

LGTM

[NonVersionable]
public unsafe bool Equals(IntPtr other) => (nint)_value == (nint)other;

public unsafe override string ToString() => ((nint)_value).ToString(CultureInfo.InvariantCulture);
Copy link
Member

Choose a reason for hiding this comment

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

Test failures are because this is forcing InvariantCulture.

Either this needs to just mirror what int32/int64 do for their respective overloads or the test needs to be updated. I would guess the former is preferred and so this should just be ((nint)_value).ToString()

Copy link
Contributor Author

Choose a reason for hiding this comment

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

that is a breaking change as previously it was invariant by default right?

Copy link
Member

Choose a reason for hiding this comment

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

Yes, but it is also a breaking change to implement IFormattable (hence the breaking-change label on #21943).

I think it is the least confusing to just make this consistent moving forward and we can direct users to explicitly specify CultureInfo.InvariantCulture moving forward, if they want to be backwards compatible. Otherwise, you end up with behavior that differs from the other primitive types and how these overloads generally work together in general.

(Unless @jkotas or someone else has a different opinion here).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

changed as this is already a breaking change, discussed w tanner somewhere else

@tannergooding tannergooding merged commit 37fdae1 into dotnet:master Apr 21, 2020
tannergooding added a commit to tannergooding/runtime that referenced this pull request Apr 21, 2020
* Add new IntPtr surface

* Add new UIntPtr API surface

* Add sequential layout to match [U]Int32

* Add interfaces and sequential layout

* Add interfaces

* Add namespaces

* Add namespaces

* Update UIntPtr.cs

* Update IntPtr.cs

* Change style

* make non versionable, elide copy

* fix style, elide copy, make non versionable

* Fix syntax error

* Fix style issues

* Fix style issues

* Update IntPtr.cs

* Update UIntPtr.cs

* Update ref assembly

* Allow comparison of intptr/uintptr in Array

* Fixed ELEMENT_TYPE cases, added tests based on Int32/UInt32 tests

* Fixes

* Update Array.cs

* Update Array.cs

* Update Array.cs

* Update ArrayTests.cs

* Update ArrayTests.cs

* Update UIntPtrTests.cs

* Update ArrayTests.cs

* fix instance methods??

* fixes

* Fixwa

* fix tests

* Add non versionables

* fix compare methods

* Fix comparison error

* fix boundary

* fix compares

* fix maxvals

* remove xunit buggy data

* silly var name error

* Update src/libraries/System.Private.CoreLib/src/Resources/Strings.resx

Co-Authored-By: Tanner Gooding <[email protected]>

* Fix ToString

Co-authored-by: Tanner Gooding <[email protected]>
tannergooding added a commit that referenced this pull request Apr 23, 2020
* Add new IntPtr/UIntPtr API surface (#307)

* Add new IntPtr surface

* Add new UIntPtr API surface

* Add sequential layout to match [U]Int32

* Add interfaces and sequential layout

* Add interfaces

* Add namespaces

* Add namespaces

* Update UIntPtr.cs

* Update IntPtr.cs

* Change style

* make non versionable, elide copy

* fix style, elide copy, make non versionable

* Fix syntax error

* Fix style issues

* Fix style issues

* Update IntPtr.cs

* Update UIntPtr.cs

* Update ref assembly

* Allow comparison of intptr/uintptr in Array

* Fixed ELEMENT_TYPE cases, added tests based on Int32/UInt32 tests

* Fixes

* Update Array.cs

* Update Array.cs

* Update Array.cs

* Update ArrayTests.cs

* Update ArrayTests.cs

* Update UIntPtrTests.cs

* Update ArrayTests.cs

* fix instance methods??

* fixes

* Fixwa

* fix tests

* Add non versionables

* fix compare methods

* Fix comparison error

* fix boundary

* fix compares

* fix maxvals

* remove xunit buggy data

* silly var name error

* Update src/libraries/System.Private.CoreLib/src/Resources/Strings.resx

Co-Authored-By: Tanner Gooding <[email protected]>

* Fix ToString

Co-authored-by: Tanner Gooding <[email protected]>

* Remove the explicit IEquatable implementation from the IntPtr/UIntPtr reference API

Co-authored-by: John <[email protected]>
@ghost ghost locked as resolved and limited conversation to collaborators Dec 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants