Tracking issue for 128-bit integer support (RFC 1504) #35118

Open
nikomatsakis opened this Issue Jul 29, 2016 · 119 comments

Comments

Projects
None yet
@nikomatsakis
Contributor

nikomatsakis commented Jul 29, 2016

Tracking issue for rust-lang/rfcs#1504.

cc @Amanieu

Blocking stabilization:

  • #41799 (Casting u128::MAX to f32 is undefined)
  • Interaction with FFI? (#35118 (comment)) - #44261
  • separately feature gate repr(i128) - #44262
  • #45676 (u/i)128 lowering for backends without native support
    • lowering still does not work for emscripten even with the work around
  • Enums with 128-bit discriminant: repr128 feature
@durka

This comment has been minimized.

Show comment
Hide comment
@durka

durka Aug 2, 2016

Contributor

Is #[repr(u128)] enum SuchWideVeryDiscriminantWow { ... } allowed?

Contributor

durka commented Aug 2, 2016

Is #[repr(u128)] enum SuchWideVeryDiscriminantWow { ... } allowed?

@Amanieu

This comment has been minimized.

Show comment
Hide comment
@Amanieu

Amanieu Aug 2, 2016

Contributor

That's a good point, I don't see any reason why it shouldn't be allowed.

Contributor

Amanieu commented Aug 2, 2016

That's a good point, I don't see any reason why it shouldn't be allowed.

@durka

This comment has been minimized.

Show comment
Hide comment
@durka

durka Aug 2, 2016

Contributor

The return type of the discriminant_value intrinsic needs to be updated, then :)

Contributor

durka commented Aug 2, 2016

The return type of the discriminant_value intrinsic needs to be updated, then :)

@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Aug 2, 2016

Contributor

Intrinsics are stuff internal to the compiler, therefore changes to them doesn’t need discussion in the RFCs.

Contributor

nagisa commented Aug 2, 2016

Intrinsics are stuff internal to the compiler, therefore changes to them doesn’t need discussion in the RFCs.

@durka

This comment has been minimized.

Show comment
Hide comment
@durka

durka Aug 2, 2016

Contributor

I know, I just wanted to mention it here since I didn't see enums discussed in the RFC.

Contributor

durka commented Aug 2, 2016

I know, I just wanted to mention it here since I didn't see enums discussed in the RFC.

@nikomatsakis nikomatsakis referenced this issue in rust-lang/rfcs Aug 23, 2016

Closed

Add i128 and u128 types #521

@est31 est31 referenced this issue Nov 20, 2016

Closed

i128 and u128 support #37900

2 of 2 tasks complete

bors added a commit that referenced this issue Dec 4, 2016

Auto merge of #37900 - est31:i128, r=eddyb
i128 and u128 support

Adds support for 128-bit integers. Rebased version of #35954 , with additional improvements.

Thanks @nagisa for mentoring this PR!

Some of the problems that were resolved:

* [x] Confirm that intrinsics work on 32 bit platforms and fix them if needed

* Wait for #37906 to get fixed, so that work on intrinsics can be completed *(worked around by merging the PR on my local setup)*

* [x] Investigate and fix linkcheck failure

[plugin-breaking-change]

cc #35118

bors added a commit that referenced this issue Dec 4, 2016

Auto merge of #37900 - est31:i128, r=eddyb
i128 and u128 support

Adds support for 128-bit integers. Rebased version of #35954 , with additional improvements.

Thanks @nagisa for mentoring this PR!

Some of the problems that were resolved:

* [x] Confirm that intrinsics work on 32 bit platforms and fix them if needed

* Wait for #37906 to get fixed, so that work on intrinsics can be completed *(worked around by merging the PR on my local setup)*

* [x] Investigate and fix linkcheck failure

[plugin-breaking-change]

cc #35118

bors added a commit that referenced this issue Dec 4, 2016

Auto merge of #37900 - est31:i128, r=eddyb
i128 and u128 support

Adds support for 128-bit integers. Rebased version of #35954 , with additional improvements.

Thanks @nagisa for mentoring this PR!

Some of the problems that were resolved:

* [x] Confirm that intrinsics work on 32 bit platforms and fix them if needed

* Wait for #37906 to get fixed, so that work on intrinsics can be completed *(worked around by merging the PR on my local setup)*

* [x] Investigate and fix linkcheck failure

[plugin-breaking-change]

cc #35118

bors added a commit that referenced this issue Dec 4, 2016

Auto merge of #37900 - est31:i128, r=eddyb
i128 and u128 support

Adds support for 128-bit integers. Rebased version of #35954 , with additional improvements.

Thanks @nagisa for mentoring this PR!

Some of the problems that were resolved:

* [x] Confirm that intrinsics work on 32 bit platforms and fix them if needed

* Wait for #37906 to get fixed, so that work on intrinsics can be completed *(worked around by merging the PR on my local setup)*

* [x] Investigate and fix linkcheck failure

[plugin-breaking-change]

cc #35118

bors added a commit that referenced this issue Dec 8, 2016

Auto merge of #37900 - est31:i128, r=eddyb
i128 and u128 support

Adds support for 128-bit integers. Rebased version of #35954 , with additional improvements.

Thanks @nagisa for mentoring this PR!

Some of the problems that were resolved:

* [x] Confirm that intrinsics work on 32 bit platforms and fix them if needed

* Wait for #37906 to get fixed, so that work on intrinsics can be completed *(worked around by merging the PR on my local setup)*

* [x] Investigate and fix linkcheck failure

[plugin-breaking-change]

cc #35118

bors added a commit that referenced this issue Dec 8, 2016

Auto merge of #37900 - est31:i128, r=eddyb
i128 and u128 support

Adds support for 128-bit integers. Rebased version of #35954 , with additional improvements.

Thanks @nagisa for mentoring this PR!

Some of the problems that were resolved:

* [x] Confirm that intrinsics work on 32 bit platforms and fix them if needed

* Wait for #37906 to get fixed, so that work on intrinsics can be completed *(worked around by merging the PR on my local setup)*

* [x] Investigate and fix linkcheck failure

[plugin-breaking-change]

cc #35118

bors added a commit that referenced this issue Dec 8, 2016

Auto merge of #37900 - est31:i128, r=eddyb
i128 and u128 support

Adds support for 128-bit integers. Rebased version of #35954 , with additional improvements.

Thanks @nagisa for mentoring this PR!

Some of the problems that were resolved:

* [x] Confirm that intrinsics work on 32 bit platforms and fix them if needed

* Wait for #37906 to get fixed, so that work on intrinsics can be completed *(worked around by merging the PR on my local setup)*

* [x] Investigate and fix linkcheck failure

[plugin-breaking-change]

cc #35118

bors added a commit that referenced this issue Dec 14, 2016

Auto merge of #37900 - est31:i128, r=eddyb
i128 and u128 support

Adds support for 128-bit integers. Rebased version of #35954 , with additional improvements.

Thanks @nagisa for mentoring this PR!

Some of the problems that were resolved:

* [x] Confirm that intrinsics work on 32 bit platforms and fix them if needed

* Wait for #37906 to get fixed, so that work on intrinsics can be completed *(worked around by merging the PR on my local setup)*

* [x] Investigate and fix linkcheck failure

[plugin-breaking-change]

cc #35118

bors added a commit that referenced this issue Dec 20, 2016

Auto merge of #38482 - est31:i128, r=eddyb
i128 and u128 support

Brings i128 and u128 support to nightly rust, behind a feature flag. The goal of this PR is to do the bulk of the work for 128 bit integer support. Smaller but just as tricky features needed for stabilisation like 128 bit enum discriminants are left for future PRs.

Rebased version of  #37900, which in turn was a rebase + improvement of #35954 . Sadly I couldn't reopen #37900 due to github. There goes my premium position in the homu queue...

[plugin-breaking-change]

cc #35118 (tracking issue)

bors added a commit that referenced this issue Dec 21, 2016

Auto merge of #38482 - est31:i128, r=eddyb
i128 and u128 support

Brings i128 and u128 support to nightly rust, behind a feature flag. The goal of this PR is to do the bulk of the work for 128 bit integer support. Smaller but just as tricky features needed for stabilisation like 128 bit enum discriminants are left for future PRs.

Rebased version of  #37900, which in turn was a rebase + improvement of #35954 . Sadly I couldn't reopen #37900 due to github. There goes my premium position in the homu queue...

[plugin-breaking-change]

cc #35118 (tracking issue)
@cmr

This comment has been minimized.

Show comment
Hide comment
@cmr

cmr Dec 21, 2016

Member

How should FFI with this type be handled? Is there any standard ABI support for these types? AFAICT, the answer is "no", which means this type should be FFI-unsafe, and the FFI unsafety lint should be updated to reject Ty{I,Ui}nt with 128-bit sizes.

Member

cmr commented Dec 21, 2016

How should FFI with this type be handled? Is there any standard ABI support for these types? AFAICT, the answer is "no", which means this type should be FFI-unsafe, and the FFI unsafety lint should be updated to reject Ty{I,Ui}nt with 128-bit sizes.

@cmr

This comment has been minimized.

Show comment
Hide comment
@cmr

cmr Dec 21, 2016

Member

cc @est31

Member

cmr commented Dec 21, 2016

cc @est31

@retep998

This comment has been minimized.

Show comment
Hide comment
@retep998

retep998 Dec 21, 2016

Member

On Windows there is most definitely no standard i128 yet because the standard compiler (msvc) does not support __int128 yet on x86. There are some really good guesses though based on the MSDN documentation.

Member

retep998 commented Dec 21, 2016

On Windows there is most definitely no standard i128 yet because the standard compiler (msvc) does not support __int128 yet on x86. There are some really good guesses though based on the MSDN documentation.

@est31

This comment has been minimized.

Show comment
Hide comment
@est31

est31 Dec 21, 2016

Contributor

Is there any standard ABI support for these types?

It depends on the architecture. SysV defines the ABI for 64 bit architectures. For x86, its most likely its not defined. Same goes for windows: it should in theory be defined for 64 bit (just sadly nobody adheres to it, its a gigantic mess), but not on x86.

This directly maps the support of the i128 type in C, and I think generally it makes little sense to have FFI for types that don't exist in C.

Contributor

est31 commented Dec 21, 2016

Is there any standard ABI support for these types?

It depends on the architecture. SysV defines the ABI for 64 bit architectures. For x86, its most likely its not defined. Same goes for windows: it should in theory be defined for 64 bit (just sadly nobody adheres to it, its a gigantic mess), but not on x86.

This directly maps the support of the i128 type in C, and I think generally it makes little sense to have FFI for types that don't exist in C.

@est31

This comment has been minimized.

Show comment
Hide comment
@est31

est31 Dec 21, 2016

Contributor

bug report in llvm about the x86_64 ABI problems: https://llvm.org/bugs/show_bug.cgi?id=31362

Contributor

est31 commented Dec 21, 2016

bug report in llvm about the x86_64 ABI problems: https://llvm.org/bugs/show_bug.cgi?id=31362

@nagisa

This comment has been minimized.

Show comment
Hide comment

bors added a commit that referenced this issue Dec 21, 2016

Auto merge of #38482 - est31:i128, r=eddyb
i128 and u128 support

Brings i128 and u128 support to nightly rust, behind a feature flag. The goal of this PR is to do the bulk of the work for 128 bit integer support. Smaller but just as tricky features needed for stabilisation like 128 bit enum discriminants are left for future PRs.

Rebased version of  #37900, which in turn was a rebase + improvement of #35954 . Sadly I couldn't reopen #37900 due to github. There goes my premium position in the homu queue...

[plugin-breaking-change]

cc #35118 (tracking issue)

bors added a commit that referenced this issue Dec 30, 2016

Auto merge of #38482 - est31:i128, r=eddyb
i128 and u128 support

Brings i128 and u128 support to nightly rust, behind a feature flag. The goal of this PR is to do the bulk of the work for 128 bit integer support. Smaller but just as tricky features needed for stabilisation like 128 bit enum discriminants are left for future PRs.

Rebased version of  #37900, which in turn was a rebase + improvement of #35954 . Sadly I couldn't reopen #37900 due to github. There goes my premium position in the homu queue...

[plugin-breaking-change]

cc #35118 (tracking issue)

bors added a commit that referenced this issue Dec 30, 2016

Auto merge of #38482 - est31:i128, r=eddyb
i128 and u128 support

Brings i128 and u128 support to nightly rust, behind a feature flag. The goal of this PR is to do the bulk of the work for 128 bit integer support. Smaller but just as tricky features needed for stabilisation like 128 bit enum discriminants are left for future PRs.

Rebased version of  #37900, which in turn was a rebase + improvement of #35954 . Sadly I couldn't reopen #37900 due to github. There goes my premium position in the homu queue...

[plugin-breaking-change]

cc #35118 (tracking issue)

bors added a commit that referenced this issue Dec 31, 2016

Auto merge of #38482 - est31:i128, r=eddyb
i128 and u128 support

Brings i128 and u128 support to nightly rust, behind a feature flag. The goal of this PR is to do the bulk of the work for 128 bit integer support. Smaller but just as tricky features needed for stabilisation like 128 bit enum discriminants are left for future PRs.

Rebased version of  #37900, which in turn was a rebase + improvement of #35954 . Sadly I couldn't reopen #37900 due to github. There goes my premium position in the homu queue...

[plugin-breaking-change]

cc #35118 (tracking issue)

bors added a commit that referenced this issue Dec 31, 2016

Auto merge of #38482 - est31:i128, r=eddyb
i128 and u128 support

Brings i128 and u128 support to nightly rust, behind a feature flag. The goal of this PR is to do the bulk of the work for 128 bit integer support. Smaller but just as tricky features needed for stabilisation like 128 bit enum discriminants are left for future PRs.

Rebased version of  #37900, which in turn was a rebase + improvement of #35954 . Sadly I couldn't reopen #37900 due to github. There goes my premium position in the homu queue...

[plugin-breaking-change]

cc #35118 (tracking issue)

bors added a commit that referenced this issue Dec 31, 2016

Auto merge of #38482 - est31:i128, r=eddyb
i128 and u128 support

Brings i128 and u128 support to nightly rust, behind a feature flag. The goal of this PR is to do the bulk of the work for 128 bit integer support. Smaller but just as tricky features needed for stabilisation like 128 bit enum discriminants are left for future PRs.

Rebased version of  #37900, which in turn was a rebase + improvement of #35954 . Sadly I couldn't reopen #37900 due to github. There goes my premium position in the homu queue...

[plugin-breaking-change]

cc #35118 (tracking issue)
@est31

This comment has been minimized.

Show comment
Hide comment
@est31

est31 Jan 5, 2017

Contributor

cc #38824

Contributor

est31 commented Jan 5, 2017

cc #38824

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Feb 26, 2018

The final comment period is now complete.

rfcbot commented Feb 26, 2018

The final comment period is now complete.

@PlasmaPower

This comment has been minimized.

Show comment
Hide comment
@PlasmaPower

PlasmaPower Mar 16, 2018

Contributor

This should be stabilized, right?

Contributor

PlasmaPower commented Mar 16, 2018

This should be stabilized, right?

@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Mar 17, 2018

Contributor

I would like to give stabilizing a feature a try :)

Does anyone know what the difference between the i128 feature and the i128_type feature is?

Contributor

mark-i-m commented Mar 17, 2018

I would like to give stabilizing a feature a try :)

Does anyone know what the difference between the i128 feature and the i128_type feature is?

@PlasmaPower

This comment has been minimized.

Show comment
Hide comment
@PlasmaPower

PlasmaPower Mar 17, 2018

Contributor

I've always used i128_type, but all the docs refer to i128. I think they might be aliases.

Contributor

PlasmaPower commented Mar 17, 2018

I've always used i128_type, but all the docs refer to i128. I think they might be aliases.

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Mar 17, 2018

Contributor

They’re likely the language features (the primitive types) vs the library features (various APIs that involve those types).

Contributor

SimonSapin commented Mar 17, 2018

They’re likely the language features (the primitive types) vs the library features (various APIs that involve those types).

@PlasmaPower

This comment has been minimized.

Show comment
Hide comment
@PlasmaPower

PlasmaPower Mar 17, 2018

Contributor

I thought so too, but both the i128 primitive and the std::i128 module pages both have i128 listed as the feature gate in the documentation.

Contributor

PlasmaPower commented Mar 17, 2018

I thought so too, but both the i128 primitive and the std::i128 module pages both have i128 listed as the feature gate in the documentation.

@cuviper

This comment has been minimized.

Show comment
Hide comment
@cuviper

cuviper Mar 17, 2018

Member

Yes, i128_type is the language feature, and i128 is for the library implementations. The latter includes all of the inherent methods you find on the primitive page.

Member

cuviper commented Mar 17, 2018

Yes, i128_type is the language feature, and i128 is for the library implementations. The latter includes all of the inherent methods you find on the primitive page.

@PlasmaPower

This comment has been minimized.

Show comment
Hide comment
@PlasmaPower

PlasmaPower Mar 17, 2018

Contributor

Oh, that's a bit confusing. Is there a reason for their separation? I'm assuming we want to stabilize both?

Contributor

PlasmaPower commented Mar 17, 2018

Oh, that's a bit confusing. Is there a reason for their separation? I'm assuming we want to stabilize both?

@durka

This comment has been minimized.

Show comment
Hide comment
@durka

durka Mar 17, 2018

Contributor

@PlasmaPower lang and lib features are always separate -- lang features are listed in src/libsyntax/feature_gate.rs and checked at various places in the compiler, while lib features are simply scraped from #[unstable] attributes in the code.

There's a third feature, repr128, that also points to this tracking issue. It covers #[repr(u128)] enums, which cause problems if you look too closely at their discriminants. This is just a note to whomever does the stabilization PR (@mark-i-m), to keep this issue open or make a new one for repr128.

Contributor

durka commented Mar 17, 2018

@PlasmaPower lang and lib features are always separate -- lang features are listed in src/libsyntax/feature_gate.rs and checked at various places in the compiler, while lib features are simply scraped from #[unstable] attributes in the code.

There's a third feature, repr128, that also points to this tracking issue. It covers #[repr(u128)] enums, which cause problems if you look too closely at their discriminants. This is just a note to whomever does the stabilization PR (@mark-i-m), to keep this issue open or make a new one for repr128.

@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Mar 17, 2018

Contributor

@durka Thanks! I will stabilize i128 and i128_type and not repr128.

Contributor

mark-i-m commented Mar 17, 2018

@durka Thanks! I will stabilize i128 and i128_type and not repr128.

@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Mar 17, 2018

Contributor

So do I make a PR for the book and reference before I make PR for the feature gate?

Contributor

mark-i-m commented Mar 17, 2018

So do I make a PR for the book and reference before I make PR for the feature gate?

@mark-i-m mark-i-m referenced this issue Mar 17, 2018

Merged

Stabilize 128-bit integers :tada: #49101

2 of 2 tasks complete
@est31

This comment has been minimized.

Show comment
Hide comment
@est31

est31 Mar 17, 2018

Contributor

@durka in fact, this separation seems to have been caused by tidy behaviour. It is relaxed since some time already: #43247 So the separation is more of a historic artifact.

Contributor

est31 commented Mar 17, 2018

@durka in fact, this separation seems to have been caused by tidy behaviour. It is relaxed since some time already: #43247 So the separation is more of a historic artifact.

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Mar 17, 2018

Contributor

Docs for the primitive type are at https://github.com/rust-lang/rust/blob/1.24.1/src/libstd/primitive_docs.rs#L766-L776. They also have a "library" #[unstable] attributes. As far as I know language feature flags don’t show up in rustdoc at all.

Contributor

SimonSapin commented Mar 17, 2018

Docs for the primitive type are at https://github.com/rust-lang/rust/blob/1.24.1/src/libstd/primitive_docs.rs#L766-L776. They also have a "library" #[unstable] attributes. As far as I know language feature flags don’t show up in rustdoc at all.

alexcrichton added a commit to alexcrichton/rust that referenced this issue Mar 23, 2018

Rollup merge of #49101 - mark-i-m:stabilize_i128, r=nagisa
Stabilize 128-bit integers 🎉

cc #35118

EDIT: This should be merged only after the following have been merged:
- [x] rust-lang-nursery/compiler-builtins#236
- [x] rust-lang/book#1230

kennytm added a commit to kennytm/rust that referenced this issue Mar 24, 2018

Rollup merge of #49101 - mark-i-m:stabilize_i128, r=nagisa
Stabilize 128-bit integers 🎉

cc #35118

EDIT: This should be merged only after the following have been merged:
- [x] rust-lang-nursery/compiler-builtins#236
- [x] rust-lang/book#1230

bors added a commit that referenced this issue Mar 24, 2018

Auto merge of #49101 - mark-i-m:stabilize_i128, r=nagisa
Stabilize 128-bit integers 🎉

cc #35118

EDIT: This should be merged only after the following have been merged:
- [x] rust-lang-nursery/compiler-builtins#236
- [x] rust-lang/book#1230

bors added a commit that referenced this issue Mar 25, 2018

Auto merge of #49101 - mark-i-m:stabilize_i128, r=nagisa
Stabilize 128-bit integers 🎉

cc #35118

EDIT: This should be merged only after the following have been merged:
- [x] rust-lang-nursery/compiler-builtins#236
- [x] rust-lang/book#1230

bors added a commit that referenced this issue Mar 26, 2018

Auto merge of #49101 - mark-i-m:stabilize_i128, r=nagisa
Stabilize 128-bit integers 🎉

cc #35118

EDIT: This should be merged only after the following have been merged:
- [x] rust-lang-nursery/compiler-builtins#236
- [x] rust-lang/book#1230
@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Mar 27, 2018

Contributor

I think this is done 🎉

Contributor

mark-i-m commented Mar 27, 2018

I think this is done 🎉

@est31

This comment has been minimized.

Show comment
Hide comment
@est31

est31 Mar 27, 2018

Contributor

@mark-i-m congrats!

Just don't close this issue yet as like @durka pointed out, the repr128 feature is still pointing to this tracking issue.

Contributor

est31 commented Mar 27, 2018

@mark-i-m congrats!

Just don't close this issue yet as like @durka pointed out, the repr128 feature is still pointing to this tracking issue.

@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Mar 27, 2018

Contributor

Could someone update the OP too create more check boxes for repr128?

Contributor

mark-i-m commented Mar 27, 2018

Could someone update the OP too create more check boxes for repr128?

@ebfull

This comment has been minimized.

Show comment
Hide comment
@ebfull

ebfull Mar 29, 2018

Contributor

The checkbox for #45676 is checked in this issue but #45676 is not actually closed. What's the status of lowering on other platforms?

Contributor

ebfull commented Mar 29, 2018

The checkbox for #45676 is checked in this issue but #45676 is not actually closed. What's the status of lowering on other platforms?

@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Mar 29, 2018

Contributor

I think that is fixed, although not in the nicest way. I closed the issue.

Contributor

nagisa commented Mar 29, 2018

I think that is fixed, although not in the nicest way. I closed the issue.

@est31

This comment has been minimized.

Show comment
Hide comment
@est31

est31 Mar 29, 2018

Contributor

@ebfull see my comment here: #35118 (comment)

i128 works on the entire x86 family as well as the ARM family. This covers all of the tier 1 platforms.
The platforms where we lack i128 support are tier 2 or 3.

What you are doing in zkcrypto/pairing#80 is exactly what I wanted to prevent by blocking stabilisation until all platforms support i128 lol, but people thought otherwise.

Contributor

est31 commented Mar 29, 2018

@ebfull see my comment here: #35118 (comment)

i128 works on the entire x86 family as well as the ARM family. This covers all of the tier 1 platforms.
The platforms where we lack i128 support are tier 2 or 3.

What you are doing in zkcrypto/pairing#80 is exactly what I wanted to prevent by blocking stabilisation until all platforms support i128 lol, but people thought otherwise.

@ebfull

This comment has been minimized.

Show comment
Hide comment
@ebfull

ebfull Mar 30, 2018

Contributor

@est31 I'm not doing zkcrypto/pairing#80 until it works on all platforms, which I mention in that issue. In the mean time all I will do is remove the i128_type feature flag, but still require users to opt into usage of u128.

Contributor

ebfull commented Mar 30, 2018

@est31 I'm not doing zkcrypto/pairing#80 until it works on all platforms, which I mention in that issue. In the mean time all I will do is remove the i128_type feature flag, but still require users to opt into usage of u128.

@est31

This comment has been minimized.

Show comment
Hide comment
@est31

est31 Mar 30, 2018

Contributor

@ebfull not blaming you. I'm partially blaming myself, thought that lowering worked already. Partially I'm blaming those people who decided to stabilize before all platforms support it. And the backend vendors who refuse to take {u,i}128 seriously.

Sadly, this is more of a "stable beta" release of i128 than an arrival of a feature that can be relied upon.

Contributor

est31 commented Mar 30, 2018

@ebfull not blaming you. I'm partially blaming myself, thought that lowering worked already. Partially I'm blaming those people who decided to stabilize before all platforms support it. And the backend vendors who refuse to take {u,i}128 seriously.

Sadly, this is more of a "stable beta" release of i128 than an arrival of a feature that can be relied upon.

@hdevalence

This comment has been minimized.

Show comment
Hide comment
@hdevalence

hdevalence Apr 1, 2018

It would be nice if there was a (documented) way to set a cargo feature as the default on a given architecture. From what I can tell this isn't quite possible, since the architecture-selection code happens with #[cfg(...)]s while the crate is being compiled, by which point the crate's features are already selected. Am I missing something?

The motivation is that even if u128s are available, it may not be desirable to use them, unless they actually correspond to instructions available on that platform.

It would be nice if there was a (documented) way to set a cargo feature as the default on a given architecture. From what I can tell this isn't quite possible, since the architecture-selection code happens with #[cfg(...)]s while the crate is being compiled, by which point the crate's features are already selected. Am I missing something?

The motivation is that even if u128s are available, it may not be desirable to use them, unless they actually correspond to instructions available on that platform.

@durka

This comment has been minimized.

Show comment
Hide comment
@durka

durka Apr 1, 2018

Contributor
Contributor

durka commented Apr 1, 2018

@hdevalence hdevalence referenced this issue in dalek-cryptography/curve25519-dalek Apr 6, 2018

Closed

Use the u64 backend by default on x86_64 #126

0 of 3 tasks complete

@kngwyu kngwyu referenced this issue in PyO3/pyo3 Jun 2, 2018

Merged

Add 128bit integer support #173

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment