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

Rust 1.18 regression - ieee754-0.2.1, from_bits #41793

Closed
brson opened this Issue May 6, 2017 · 11 comments

Comments

Projects
None yet
5 participants
@brson
Copy link
Contributor

brson commented May 6, 2017

error: use of unstable library feature 'float_bits_conv': recently added (see issue #40470)
   --> src/lib.rs:417:17
    |
417 |                 Self::from_bits(bits)
    |                 ^^^^^^^^^^^^^^^
...
609 | mk_impl!(f32, u32, i16, u8, u32, 8, 23);
    | ---------------------------------------- in this macro invocation

error: use of unstable library feature 'float_bits_conv': recently added (see issue #40470)
   --> src/lib.rs:417:17
    |
417 |                 Self::from_bits(bits)
    |                 ^^^^^^^^^^^^^^^
...
610 | mk_impl!(f64, u64, i16, u16, u64, 11, 52);
    | ------------------------------------------ in this macro invocation

error: use of unstable library feature 'float_bits_conv': recently added (see issue #40470)
   --> src/lib.rs:431:17
    |
431 |                 Self::from_bits(bits)
    |                 ^^^^^^^^^^^^^^^
...
609 | mk_impl!(f32, u32, i16, u8, u32, 8, 23);
    | ---------------------------------------- in this macro invocation

error: use of unstable library feature 'float_bits_conv': recently added (see issue #40470)
   --> src/lib.rs:431:17
    |
431 |                 Self::from_bits(bits)
    |                 ^^^^^^^^^^^^^^^
...
610 | mk_impl!(f64, u64, i16, u16, u64, 11, 52);
    | ------------------------------------------ in this macro invocation

error: use of unstable library feature 'float_bits_conv': recently added (see issue #40470)
   --> src/lib.rs:458:17
    |
458 |                 Self::from_bits(
    |                 ^^^^^^^^^^^^^^^
...
609 | mk_impl!(f32, u32, i16, u8, u32, 8, 23);
    | ---------------------------------------- in this macro invocation

error: use of unstable library feature 'float_bits_conv': recently added (see issue #40470)
   --> src/lib.rs:458:17
    |
458 |                 Self::from_bits(
    |                 ^^^^^^^^^^^^^^^
...
610 | mk_impl!(f64, u64, i16, u16, u64, 11, 52);
    | ------------------------------------------ in this macro invocation

error: aborting due to 6 previous errors

error: build failed

This is due to a new unstable inherent method introduced in #39271.

Mentioned already here.

cc @est31 @huonw

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented May 6, 2017

Also affects audrey-0.1.0 cc @mitchmindtree

@est31

This comment has been minimized.

Copy link
Contributor

est31 commented May 6, 2017

lewton 0.5.1 stops depending on ieee754. audrey afaik only needs the crate due to lewton, so afaik the problem should be resolved for audrey, given a Cargo.lock update.

EDIT: tested building audrey master now, works great.

@nagisa

This comment has been minimized.

Copy link
Contributor

nagisa commented May 6, 2017

XIB. We could consider an alternative name.

@est31

This comment has been minimized.

Copy link
Contributor

est31 commented May 6, 2017

Quoting @rkruppe 's comment from the linked thread:

RFC 1105 laid out that adding inherent methods is a minor change so it's up to the team(s) to decide whether we're okay with the practical impact of the change.

When implementing the feature, I was inspired by the name, but didn't think it would cause breakage, instead the ieee754 crate would shadow it. Sorry for that!

I think from_bits is the best name for it, but given the breakage its choice causes I'm neutral.

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented May 6, 2017

XIB = "expected impl breakage"

@nagisa

This comment has been minimized.

Copy link
Contributor

nagisa commented May 7, 2017

It seems to me like the ideal fix would be expedited stabilisation of the function in question. The behaviour of implementation in the crate is mildly different (difference being handling of the signalling NaN) from the implementation in libstd, but it doesn’t seem to me like that would alter functionality of the crate in a detrimental way.

Of course, if we do that, we must keep in mind that fixing this by stabilising a somewhat incompatible (albeit better) method is threading a potentially thin line between "silently breaks code" and "seamless upgrade".

@est31

This comment has been minimized.

Copy link
Contributor

est31 commented May 7, 2017

It seems to me like the ideal fix would be expedited stabilisation of the function in question.

@BurntSushi wanted to review the function before that happens.

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented May 7, 2017

Also affects radix-heap 0.2.0 cc @noctune

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented May 10, 2017

Discussed this at libs triage our conclusion was that we're unlikley to back out these methods, but if any crates have difficulty updating we can reconsider!

@crypto-universe

This comment has been minimized.

Copy link
Contributor

crypto-universe commented May 13, 2017

Affects ramp 0.3.3 cc @Aatch

@nagisa nagisa added the relnotes label May 18, 2017

@nagisa

This comment has been minimized.

Copy link
Contributor

nagisa commented May 18, 2017

Lets make sure to mention this in the release notes.

@nagisa nagisa closed this May 18, 2017

@kennytm kennytm referenced this issue Sep 11, 2017

Open

Tracking issue for clamp RFC #44095

2 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.