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

Implement From<char> for u64 and u128. #79502

Merged
merged 2 commits into from
Jan 10, 2021

Conversation

Julian-Wollersberger
Copy link
Contributor

With this PR you can write

let u = u64::from('👤');
let u = u128::from('👤');

Previously, you could already write as conversions (Playground link):

// Lossless conversions
dbg!('👤' as u32);    // Prints 128100
dbg!('👤' as u64);    // Prints 128100
dbg!('👤' as u128);   // Prints 128100

// truncates, thus no `From` impls.
dbg!('👤' as u8);     // Prints 100
dbg!('👤' as u16);    // Prints 62564

// These `From` impls already exist.
dbg!(u32::from('👤'));               // Prints 128100
dbg!(u64::from(u32::from('👤')));    // Prints 128100

The idea is from @gendx who opened this Internals thread, and @withoutboats responded that someone should open a PR for it.
Some people mentioned From<char> impls for f32 and f64, but that doesn't seem correct to me, so I didn't include them here.

I don't know what the feature should be named. Must it be registered somewhere, like unstable features?

r? @withoutboats

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 28, 2020
@Julian-Wollersberger
Copy link
Contributor Author

@rustbot modify labels: +T-libs +relnotes +C-enhancement

@rustbot
Copy link
Collaborator

rustbot commented Nov 28, 2020

Error: Label relnotes can only be set by Rust team members

Please let @rust-lang/release know if you're having trouble with this bot.

@m-ou-se m-ou-se added needs-fcp This change is insta-stable, so needs a completed FCP to proceed. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Nov 28, 2020
@scottmcm
Copy link
Member

Some people mentioned From<char> impls for f32 and f64, but that doesn't seem correct to me, so I didn't include them here.

Could you elaborate on why? It seems like the same "These From impls already exist" argument would apply just as well for f64, since f64::from(u32::from('👤')) also works.

@withoutboats
Copy link
Contributor

Conversion to u64 and u128 have pretty obvious utility (you want the integer representation of the char in a format which has reserved a certain number of bits for this data), to float not so much. Conversion to floats can be added by someone who has need of the feature.

@withoutboats
Copy link
Contributor

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Nov 28, 2020

Team member @withoutboats has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Nov 28, 2020
@withoutboats
Copy link
Contributor

I don't know what the feature should be named. Must it be registered somewhere, like unstable features?

What you've done is perfect, thanks!

@m-ou-se
Copy link
Member

m-ou-se commented Nov 29, 2020

I don't think these From implementations fit with the rest of the interface of char.

char isn't seen anywhere in Rust as a numeric/integral type, like the integer types are. As @scottmcm said on the internals thread, it's somewhat like a struct char(u32);; a type that uses u32 as the underlying representation. It is Into<u32> and TryFrom<u32> because of this special relationship with u32. It even has a char::from_u32 and from_u32_unchecked.

If we really want to make char behave more like an integer (which I don't think we should), then conversions to only u64 and u128 would be incomplete. Every code point is also representable as a i32, i64 and i128. And we should then probably also have TryFrom<u64> for char, etc. And (as @scottmcm already mentioned) possibly conversions to and from floating point values too. I don't think this is the direction char should go. (Would we expect num::BigInt to implement From<char>?)

It's unfortunate that currently the way to get the codepoint as u32 from a char is c as u32 or u32::from(c). This makes u64::from(u32::from(c)) just look redundant. If char had a .as_u32() or .codepoint() (just like char::from_u32), c.as_u32().into() or u64::from(c.codepoint()) would look more reasonable.

@withoutboats
Copy link
Contributor

I think this entire line of discussion is overthinking it.. as was pointed out on internals, we already have From<u8> for char, which has nothing inherently to do with u8 having a "special relationship" with char, as it losslessly converts bit patterns that are non-ASCII into chars.

This sort of philosophical discussion about "what a char is" is not very interesting to me. Users sometimes have code which has guaranteed that their value is within the valid bitrange for char (and are guaranteeing that by using our char type) but need to pass that value to an interface accepting a broader range of values. I see no compelling reason to make this more difficult for them.

@m-ou-se
Copy link
Member

m-ou-se commented Nov 29, 2020

We don't have a From<u16> for char, and the From<u8> for char does exists because of the special relationship between u8 and char. u8 is used for ascii characters; it even has methods specifically for ascii. Unicode codepoints (char) are a superset of ascii on purpose. The decision to have that as a non-faillible conversion, and thus include non-ascii characters as well, was well thought out and made based on the fact that unicode codepoints 128-255 match ISO-8859-1.

code which has guaranteed that their value is within the valid bitrange for char (and are guaranteeing that by using our char type) but need to pass that value to an interface accepting a broader range of values

Then why only u64 and u128? Plenty of C code uses int/i32 for these things, char in C is often signed, and if you want to pass a codepoint as number to javascript/json, it'd be a f64.

@withoutboats
Copy link
Contributor

Then why only u64 and u128? Plenty of C code uses int/i32 for these things, char in C is often signed, and if you want to pass a codepoint as number to javascript/json, it'd be a f64.

If anyone has strong enough desire for those APIs to make a PR, I would check my box to add them as well. What I favor is pragmatism: just as we should not not add these APIs for philosophical reasons, we also should not add them just for the sake of being "complete" as well.

@m-ou-se
Copy link
Member

m-ou-se commented Nov 29, 2020

Storing a codepoint in an int doesn't seem like a very philosophical situation.

I would check my box to add them as well.

I probably wouldn't check mine for floats or TryFrom<u64>, which makes me hesitant to check it here, unless there is something fundamentally different about the conversions in this PR.

@BurntSushi
Copy link
Member

@m-ou-se I'd like to try understanding your position better. Is it a "these don't make conceptual sense," or do you see some practical disadvantage here?

When I saw this proposal, my thinking was on similar lines as @withoutboats. In particular, the "I need to guarantee some value is within a range but also need to pass it to some interface with a broader range" made sense to me. Granted, it probably doesn't come up often for char (it's already somewhat rare to even bother with the u32 version of char), so the upside here is pretty small. But I guess I also perceive the downside as pretty small. What do we gain by making the user do u64::from(u32::from(some_char))?

Also, @m-ou-se, as a practical matter, depending on how you feel on the matter, you may want to register a concern with the FCP bot. I think that will block the FCP from passing even if all-but-two members check their boxes. And I only say this since you're new to the team and I'm not sure if you know about it or not!

@m-ou-se
Copy link
Member

m-ou-se commented Nov 29, 2020

Also, @m-ou-se, as a practical matter, depending on how you feel on the matter, you may want to register a concern with the FCP bot. I think that will block the FCP from passing even if all-but-two members check their boxes. And I only say this since you're new to the team and I'm not sure if you know about it or not!

Thanks :) I'm aware. I didn't raise a concern with the bot on purpose, if the majority of the team agrees, I don't want to block this.

I'd like to try understanding your position better. Is it a "these don't make conceptual sense," or do you see some practical disadvantage here?

I just want to have an idea of which other char conversions we would and would not consider okay to add in the future. With most changes, we'd have a period of unstability in which we can see what other changes come in, and have more time to consider how it fits in with the rest of the (future) interface. Since this is insta-stable, we should at least discuss the (potential) surrounding APIs a bit, such as char::from_u32, TryFrom<u64> and From<char> for f64. I very much agree with boats that we shouldn't block things on philosophical concerns, but I don't think we can make decisions like this entirely in isolation. Using signed integers or floats for codepoints is a very common and real thing.

So far, u32 has been given the special treatment as the integer type for codepoints, with a dedicated char::from_u32, etc. Adding conversions to other integer types raises the question if u32 is still special, and what that means for the rest of the interface.

What do we gain by making the user do u64::from(u32::from(some_char))?

I mentioned above I think that's not great. u64::from(some_char.codepoint()) or something would look nicer. And maybe u64::from(some_char) is fine after all.

I just want to make sure we consider the surroundings of this API a bit. I can't vote on these two specific conversions without at least considering what this means for the related ones. (TryFrom, signed integers, floats, and from_u32.) Especially since multiple people already raised questions about this on the internals thread.

@BurntSushi
Copy link
Member

@m-ou-se Gotya. That makes sense to me.

As somewhat of an irrelevant aside, when I build APIs like char in other libraries, I usually don't bother too much with From impls. Instead, I'll do as you suggested: add specific methods like as_codepoint instead. If only because it makes it more discoverable. This doesn't mean I don't also add From impls eventually. Just depends on whether someone wants it or not.

Otherwise, yeah, if we add these then I guess it does make some sense to think about other cases.

Using signed integers or floats for codepoints is a very common and real thing.

If we take "common" here to be "relatively common", then I can see signed integers maybe because of FFI or other interfaces that require signed integers? But I'm having a hard time coming up with cases where floats are useful or even relatively common. Can you say more about those?

Otherwise, yeah, I would personally be okay with From impls for signed integers. I'm less sure about floats, but don't feel that strongly about them. In particular, I just don't see much downside from adding them.

So far, u32 has been given the special treatment as the integer type for codepoints, with a dedicated char::from_u32, etc. Adding conversions to other integer types raises the question if u32 is still special, and what that means for the rest of the interface.

Yes, I think u32 is still special. The fact that char is a u32 is very nearly guaranteed by the API docs. And when you do need to deal with a codepoint as an integer, u32 is almost certainly the most common. I do see a special relationship between char and u32 and wouldn't want to add things like from_u64. (Is that what you're getting at here? Not sure.)

@Julian-Wollersberger
Copy link
Contributor Author

I don't have a strong opinion here, and no personal use case. I made this PR because it was an easy contribution.

Some people mentioned From<char> impls for f32 and f64, but that doesn't seem correct to me, so I didn't include them here.

Could you elaborate on why? It seems like the same "These From impls already exist" argument would apply just as well for f64, since f64::from(u32::from('👤')) also works.

My intuition is that From and Into are only for the "obviously correct" conversions. When the conversion can be lossy, you have to use as or TryFrom / TryInto. Also, as conversions have non-obvious semantics, in the sense that I always need to look up if a conversion is defined to truncate, panic, saturate or bitwise reinterpret.

Since char is defined as a 4 byte Unicode scalar, the conversion to u32 is the most obvious: "Give me that Unicode scalar as a number." Conversion to u64 and u128 is IMO also obvious and unambiguous: "Give me that Unicode scalar as a number, but use more bits than necessary."

For converting char to f32 or f64, it's not obvious to me what it should do. Can the sign be negative? Can there be a NaN character? What impact would rounding have? Apparently this can be answered with "No, no and doesn't happen", but to avoid this confusion I'm against adding From impls here.

I'm not so sure about From<char> for {i32, i64, i128}, though I'd argue there can also be confusion if negative scalar values could be a thing. Again, you would need to look up what will happen precisely to learn that Unicode is specified up to 24 bits, so no actual problems would arise.

The biggest use case I see for char conversions to u64 and u128 is to give better control over the memory layout. Additional conversions wouldn't give any more control. They can still be done with as anyway.

@withoutboats
Copy link
Contributor

I basically agree that the problem with float is that it doesn't feel as completely obvious as u64 and u128. But if there were someone trying to bind to some JavaScript API that takes unicode scalars as a float and wanted Into<f64>, I wouldn't object to adding it.

I also think a char method called codepoint or something similar that is equivalent to casting to u32 would be a positive addition to std, because sometimes code is clearer if you use a specifically named function instead of the generic conversion.

@rfcbot rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Dec 9, 2020
@rfcbot
Copy link

rfcbot commented Dec 9, 2020

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Dec 9, 2020
@rfcbot rfcbot added the finished-final-comment-period The final comment period is finished for this PR / Issue. label Dec 19, 2020
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Dec 31, 2020
@Julian-Wollersberger
Copy link
Contributor Author

This slipped a release and I updated the version to 1.51.
@withoutboats can you merge this? Thanks!

@withoutboats
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Jan 9, 2021

📌 Commit e8cb72c has been approved by withoutboats

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 9, 2021
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Jan 10, 2021
…u64, r=withoutboats

Implement From<char> for u64 and u128.

With this PR you can write
```
let u = u64::from('👤');
let u = u128::from('👤');
```

Previously, you could already write `as` conversions ([Playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=cee18febe28e69024357d099f07ca081)):
```
// Lossless conversions
dbg!('👤' as u32);    // Prints 128100
dbg!('👤' as u64);    // Prints 128100
dbg!('👤' as u128);   // Prints 128100

// truncates, thus no `From` impls.
dbg!('👤' as u8);     // Prints 100
dbg!('👤' as u16);    // Prints 62564

// These `From` impls already exist.
dbg!(u32::from('👤'));               // Prints 128100
dbg!(u64::from(u32::from('👤')));    // Prints 128100
```

The idea is from `@gendx` who opened [this Internals thread](https://internals.rust-lang.org/t/implement-from-char-for-u64/13454), and `@withoutboats` responded that someone should open a PR for it.
Some people mentioned `From<char>` impls for `f32` and `f64`, but that doesn't seem correct to me, so I didn't include them here.

I don't know what the feature should be named. Must it be registered somewhere, like unstable features?

r? `@withoutboats`
This was referenced Jan 10, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 10, 2021
Rollup of 9 pull requests

Successful merges:

 - rust-lang#79502 (Implement From<char> for u64 and u128.)
 - rust-lang#79968 (Improve core::ptr::drop_in_place debuginfo)
 - rust-lang#80774 (Fix safety comment)
 - rust-lang#80801 (Use correct span for structured suggestion)
 - rust-lang#80803 (Remove useless `fill_in` function)
 - rust-lang#80820 (Support `download-ci-llvm` on NixOS)
 - rust-lang#80825 (Remove under-used ImplPolarity enum)
 - rust-lang#80850 (Allow #[rustc_builtin_macro = "name"])
 - rust-lang#80857 (Add comment to `Vec::truncate` explaining `>` vs `>=`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors
Copy link
Contributor

bors commented Jan 10, 2021

⌛ Testing commit e8cb72c with merge 34628e5...

@bors bors merged commit 5c0f5b6 into rust-lang:master Jan 10, 2021
@rustbot rustbot added this to the 1.51.0 milestone Jan 10, 2021
@Julian-Wollersberger Julian-Wollersberger deleted the from_char_for_u64 branch January 10, 2021 12:07
@Aehmlo Aehmlo mentioned this pull request Mar 25, 2021
wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request Apr 10, 2021
Pkgsrc changes:
 * Remove one SunOS patch, apparently no longer needed.
 * Adapt one patch for Darwin, adjust cargo checksum accordingly.
 * Adjust bootstraps to version 1.50.0.

Version 1.51.0 (2021-03-25)
============================

Language
--------
- [You can now parameterize items such as functions, traits, and
  `struct`s by constant values in addition to by types and
  lifetimes.][79135] Also known as "const generics" E.g. you can
  now write the following. Note:  Only values of primitive integers,
  `bool`, or `char` types are currently permitted.

  ```rust
  struct GenericArray<T, const LENGTH: usize> {
      inner: [T; LENGTH]
  }

  impl<T, const LENGTH: usize> GenericArray<T, LENGTH> {
      const fn last(&self) -> Option<&T> {
          if LENGTH == 0 {
              None
          } else {
              Some(&self.inner[LENGTH - 1])
          }
      }
  }
  ```

Compiler
--------

- [Added the `-Csplit-debuginfo` codegen option for macOS platforms.][79570]
  This option controls whether debug information is split across
  multiple files or packed into a single file. **Note** This option
  is unstable on other platforms.
- [Added tier 3\* support for `aarch64_be-unknown-linux-gnu`,
  `aarch64-unknown-linux-gnu_ilp32`, and
  `aarch64_be-unknown-linux-gnu_ilp32` targets.][81455]
- [Added tier 3 support for `i386-unknown-linux-gnu` and
  `i486-unknown-linux-gnu` targets.][80662]
- [The `target-cpu=native` option will now detect individual features
  of CPUs.][80749]
- [Rust now uses `inline-asm` for stack probes when used with LLVM
  11.0.1+][77885]

\* Refer to Rust's [platform support page][forge-platform-support]
for more information on Rust's tiered platform support.

Libraries
---------

- [`Box::downcast` is now also implemented for any `dyn Any + Send
  + Sync` object.][80945]
- [`str` now implements `AsMut<str>`.][80279]
- [`u64` and `u128` now implement `From<char>`.][79502]
- [`Error` is now implemented for `&T` where `T` implements `Error`.][75180]
- [`Poll::{map_ok, map_err}` are now implemented for `Poll<Option<Result<T,
  E>>>`.][80968]
- [`unsigned_abs` is now implemented for all signed integer types.][80959]
- [`io::Empty` now implements `io::Seek`.][78044]
- [`rc::Weak<T>` and `sync::Weak<T>`'s methods such as `as_ptr`
  are now implemented for `T: ?Sized` types.][80764]

Stabilized APIs
---------------

- [`Arc::decrement_strong_count`]
- [`Arc::increment_strong_count`]
- [`Once::call_once_force`]
- [`Peekable::next_if_eq`]
- [`Peekable::next_if`]
- [`Seek::stream_position`]
- [`array::IntoIter`]
- [`panic::panic_any`]
- [`ptr::addr_of!`]
- [`ptr::addr_of_mut!`]
- [`slice::fill_with`]
- [`slice::split_inclusive_mut`]
- [`slice::split_inclusive`]
- [`slice::strip_prefix`]
- [`slice::strip_suffix`]
- [`str::split_inclusive`]
- [`sync::OnceState`]
- [`task::Wake`]

Cargo
-----
- [Added the `split-debuginfo` profile option to control the -Csplit-debuginfo
  codegen option.][cargo/9112]
- [Added the `resolver` field to `Cargo.toml` to enable the new
  feature resolver and CLI option behavior.][cargo/8997] Version
  2 of the feature resolver will try to avoid unifying features of
  dependencies where that unification could be unwanted.  Such as
  using the same dependency with a `std` feature in a build scripts
  and proc-macros, while using the `no-std` feature in the final
  binary. See the [Cargo book documentation][[email protected]]
  for more information on the feature.

Rustdoc
-------
- [Rustdoc will now include documentation for methods available
  from `Deref` traits.][80653]
- [You can now provide a `--default-theme` flag which sets the
  default theme to use for documentation.][79642]

Various improvements to intra-doc links:

- [You can link to non-path primitives such as `slice`.][80181]
- [You can link to associated items.][74489]
- [You can now include generic parameters when linking to items,
  like `Vec<T>`.][76934]

Misc
----
- [You can now pass `--include-ignored` to tests (e.g. with
  `cargo test -- --include-ignored`) to include testing tests marked
  `#[ignore]`.][80053]

Compatibility Notes
-------------------

- [WASI platforms no longer use the `wasm-bindgen` ABI, and instead
  use the wasm32 ABI.][79998]
- [`rustc` no longer promotes division, modulo and indexing operations
  to `const` that could fail.][80579]

- [The minimum version of glibc for the following platforms has
  been bumped to version 2.31 for the distributed artifacts.][81521]
    - `armv5te-unknown-linux-gnueabi`
    - `sparc64-unknown-linux-gnu`
    - `thumbv7neon-unknown-linux-gnueabihf`
    - `armv7-unknown-linux-gnueabi`
    - `x86_64-unknown-linux-gnux32`

Internal Only
-------------

- [Consistently avoid constructing optimized MIR when not doing codegen][80718]

[79135]: rust-lang/rust#79135
[74489]: rust-lang/rust#74489
[76934]: rust-lang/rust#76934
[79570]: rust-lang/rust#79570
[80181]: rust-lang/rust#80181
[79642]: rust-lang/rust#79642
[80945]: rust-lang/rust#80945
[80279]: rust-lang/rust#80279
[80053]: rust-lang/rust#80053
[79502]: rust-lang/rust#79502
[75180]: rust-lang/rust#75180
[79135]: rust-lang/rust#79135
[81521]: rust-lang/rust#81521
[80968]: rust-lang/rust#80968
[80959]: rust-lang/rust#80959
[80718]: rust-lang/rust#80718
[80653]: rust-lang/rust#80653
[80579]: rust-lang/rust#80579
[79998]: rust-lang/rust#79998
[78044]: rust-lang/rust#78044
[81455]: rust-lang/rust#81455
[80764]: rust-lang/rust#80764
[80749]: rust-lang/rust#80749
[80662]: rust-lang/rust#80662
[77885]: rust-lang/rust#77885
[cargo/8997]: rust-lang/cargo#8997
[cargo/9112]: rust-lang/cargo#9112
[[email protected]]: https://doc.rust-lang.org/nightly/cargo/reference/features.html#feature-resolver-version-2
[`Once::call_once_force`]: https://doc.rust-lang.org/stable/std/sync/struct.Once.html#method.call_once_force
[`sync::OnceState`]: https://doc.rust-lang.org/stable/std/sync/struct.OnceState.html
[`panic::panic_any`]: https://doc.rust-lang.org/stable/std/panic/fn.panic_any.html
[`slice::strip_prefix`]: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.strip_prefix
[`slice::strip_suffix`]: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.strip_prefix
[`Arc::increment_strong_count`]: https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.increment_strong_count
[`Arc::decrement_strong_count`]: https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.decrement_strong_count
[`slice::fill_with`]: https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.fill_with
[`ptr::addr_of!`]: https://doc.rust-lang.org/nightly/std/ptr/macro.addr_of.html
[`ptr::addr_of_mut!`]: https://doc.rust-lang.org/nightly/std/ptr/macro.addr_of_mut.html
[`array::IntoIter`]: https://doc.rust-lang.org/nightly/std/array/struct.IntoIter.html
[`slice::split_inclusive`]: https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.split_inclusive
[`slice::split_inclusive_mut`]: https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.split_inclusive_mut
[`str::split_inclusive`]: https://doc.rust-lang.org/nightly/std/primitive.str.html#method.split_inclusive
[`task::Wake`]: https://doc.rust-lang.org/nightly/std/task/trait.Wake.html
[`Seek::stream_position`]: https://doc.rust-lang.org/nightly/std/io/trait.Seek.html#method.stream_position
[`Peekable::next_if`]: https://doc.rust-lang.org/nightly/std/iter/struct.Peekable.html#method.next_if
[`Peekable::next_if_eq`]: https://doc.rust-lang.org/nightly/std/iter/struct.Peekable.html#method.next_if_eq
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request May 26, 2021
Pkgsrc changes:
 * Add support for the big-endian arm64 NetBSD target (aarch64_be).
 * On NetBSD/i386, use the i586 (pentium) bootstrap kit variant in
   preference to i686.
 * Adjust patches, re-compute line offsets, re-compute crate checksums.
 * Remove a patch which was either integrated upstream and/or no longer
   applies.
 * Bump bootstraps to 1.50.0.
 * Move conditionals until after bsd.prefs.mk so that they work...
 * Default to "dist" build target if cross-compiling, but allow
   also to override via rust.BUILD_TARGET.
 * Allow overriding MAKE_JOBS_SAFE via rust.MAKE_JOBS_SAFE if you
   want a different trade-off between occasional breakage and performance.
 * Adjust platform.mk according to work already done in wip/rust/
 * Add a patch to optimize the install.sh script used to install binary
   bootstraps to not do so many forks; use case/esac and parameter expansion
   instead of grep, sed and cut.
 * Drop building documentation for the binary bootstrap kits.  This will
   also impact the lang/rust-bin package.  For full documentation, build
   or install lang/rust as a package.

Upstream changes:

Version 1.51.0 (2021-03-25)
============================

Language
--------
- [You can now parameterize items such as functions, traits, and
  `struct`s by constant values in addition to by types and
  lifetimes.][79135] Also known as "const generics" E.g. you can
  now write the following. Note:  Only values of primitive integers,
  `bool`, or `char` types are currently permitted.
  ```rust
  struct GenericArray<T, const LENGTH: usize> {
      inner: [T; LENGTH]
  }

  impl<T, const LENGTH: usize> GenericArray<T, LENGTH> {
      const fn last(&self) -> Option<&T> {
          if LENGTH == 0 {
              None
          } else {
              Some(&self.inner[LENGTH - 1])
          }
      }
  }
  ```

Compiler
--------

- [Added the `-Csplit-debuginfo` codegen option for macOS platforms.][79570]
  This option controls whether debug information is split across
  multiple files or packed into a single file. **Note** This option
  is unstable on other platforms.
- [Added tier 3\* support for `aarch64_be-unknown-linux-gnu`,
  `aarch64-unknown-linux-gnu_ilp32`, and
  `aarch64_be-unknown-linux-gnu_ilp32` targets.][81455]

- [Added tier 3 support for `i386-unknown-linux-gnu` and
  `i486-unknown-linux-gnu` targets.][80662]

- [The `target-cpu=native` option will now detect individual features
  of CPUs.][80749]

\* Refer to Rust's [platform support page][platform-support-doc] for more
information on Rust's tiered platform support.

Libraries
---------

- [`Box::downcast` is now also implemented for any `dyn Any + Send
  + Sync` object.][80945]
- [`str` now implements `AsMut<str>`.][80279]
- [`u64` and `u128` now implement `From<char>`.][79502]
- [`Error` is now implemented for `&T` where `T` implements `Error`.][75180]
- [`Poll::{map_ok, map_err}` are now implemented for
  `Poll<Option<Result<T,E>>>`.][80968]
- [`unsigned_abs` is now implemented for all signed integer types.][80959]
- [`io::Empty` now implements `io::Seek`.][78044]
- [`rc::Weak<T>` and `sync::Weak<T>`'s methods such as `as_ptr`
  are now implemented for `T: ?Sized` types.][80764]
- [`Div` and `Rem` by their `NonZero` variant is now implemented
  for all unsigned integers.][79134]

Stabilized APIs
---------------

- [`Arc::decrement_strong_count`]
- [`Arc::increment_strong_count`]
- [`Once::call_once_force`]
- [`Peekable::next_if_eq`]
- [`Peekable::next_if`]
- [`Seek::stream_position`]
- [`array::IntoIter`]
- [`panic::panic_any`]
- [`ptr::addr_of!`]
- [`ptr::addr_of_mut!`]
- [`slice::fill_with`]
- [`slice::split_inclusive_mut`]
- [`slice::split_inclusive`]
- [`slice::strip_prefix`]
- [`slice::strip_suffix`]
- [`str::split_inclusive`]
- [`sync::OnceState`]
- [`task::Wake`]
- [`VecDeque::range`]
- [`VecDeque::range_mut`]

Cargo
-----
- [Added the `split-debuginfo` profile option to control the -Csplit-debuginfo
  codegen option.][cargo/9112]
- [Added the `resolver` field to `Cargo.toml` to enable the new
  feature resolver and CLI option behavior.][cargo/8997] Version
  2 of the feature resolver will try to avoid unifying features of
  dependencies where that unification could be unwanted.  Such as
  using the same dependency with a `std` feature in a build scripts
  and proc-macros, while using the `no-std` feature in the final
  binary. See the [Cargo book documentation][[email protected]]
  for more information on the feature.

Rustdoc
-------

- [Rustdoc will now include documentation for methods available
  from _nested_ `Deref` traits.][80653]
- [You can now provide a `--default-theme` flag which sets the
  default theme to use for documentation.][79642]

Various improvements to intra-doc links:

- [You can link to non-path primitives such as `slice`.][80181]
- [You can link to associated items.][74489]
- [You can now include generic parameters when linking to items,
  like `Vec<T>`.][76934]

Misc
----
- [You can now pass `--include-ignored` to tests (e.g. with
  `cargo test -- --include-ignored`) to include testing tests marked
  `#[ignore]`.][80053]

Compatibility Notes
-------------------

- [WASI platforms no longer use the `wasm-bindgen` ABI, and instead
  use the wasm32 ABI.][79998]
- [`rustc` no longer promotes division, modulo and indexing operations
  to `const` that could fail.][80579]
- [The minimum version of glibc for the following platforms has
  been bumped to version 2.31 for the distributed artifacts.][81521]
    - `armv5te-unknown-linux-gnueabi`
    - `sparc64-unknown-linux-gnu`
    - `thumbv7neon-unknown-linux-gnueabihf`
    - `armv7-unknown-linux-gnueabi`
    - `x86_64-unknown-linux-gnux32`
- [`atomic::spin_loop_hint` has been deprecated.][80966] It's
  recommended to use `hint::spin_loop` instead.

Internal Only
-------------

- [Consistently avoid constructing optimized MIR when not doing codegen][80718]

[79135]: rust-lang/rust#79135
[74489]: rust-lang/rust#74489
[76934]: rust-lang/rust#76934
[79570]: rust-lang/rust#79570
[80181]: rust-lang/rust#80181
[79642]: rust-lang/rust#79642
[80945]: rust-lang/rust#80945
[80279]: rust-lang/rust#80279
[80053]: rust-lang/rust#80053
[79502]: rust-lang/rust#79502
[75180]: rust-lang/rust#75180
[79135]: rust-lang/rust#79135
[81521]: rust-lang/rust#81521
[80968]: rust-lang/rust#80968
[80959]: rust-lang/rust#80959
[80718]: rust-lang/rust#80718
[80653]: rust-lang/rust#80653
[80579]: rust-lang/rust#80579
[79998]: rust-lang/rust#79998
[78044]: rust-lang/rust#78044
[81455]: rust-lang/rust#81455
[80764]: rust-lang/rust#80764
[80749]: rust-lang/rust#80749
[80662]: rust-lang/rust#80662
[79134]: rust-lang/rust#79134
[80966]: rust-lang/rust#80966
[cargo/8997]: rust-lang/cargo#8997
[cargo/9112]: rust-lang/cargo#9112
[[email protected]]: https://doc.rust-lang.org/nightly/cargo/reference/features.html#feature-resolver-version-2
[`Once::call_once_force`]: https://doc.rust-lang.org/stable/std/sync/struct.Once.html#method.call_once_force
[`sync::OnceState`]: https://doc.rust-lang.org/stable/std/sync/struct.OnceState.html
[`panic::panic_any`]: https://doc.rust-lang.org/stable/std/panic/fn.panic_any.html
[`slice::strip_prefix`]: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.strip_prefix
[`slice::strip_suffix`]: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.strip_prefix
[`Arc::increment_strong_count`]: https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.increment_strong_count
[`Arc::decrement_strong_count`]: https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.decrement_strong_count
[`slice::fill_with`]: https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.fill_with
[`ptr::addr_of!`]: https://doc.rust-lang.org/nightly/std/ptr/macro.addr_of.html
[`ptr::addr_of_mut!`]: https://doc.rust-lang.org/nightly/std/ptr/macro.addr_of_mut.html
[`array::IntoIter`]: https://doc.rust-lang.org/nightly/std/array/struct.IntoIter.html
[`slice::split_inclusive`]: https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.split_inclusive
[`slice::split_inclusive_mut`]: https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.split_inclusive_mut
[`str::split_inclusive`]: https://doc.rust-lang.org/nightly/std/primitive.str.html#method.split_inclusive
[`task::Wake`]: https://doc.rust-lang.org/nightly/std/task/trait.Wake.html
[`Seek::stream_position`]: https://doc.rust-lang.org/nightly/std/io/trait.Seek.html#method.stream_position
[`Peekable::next_if`]: https://doc.rust-lang.org/nightly/std/iter/struct.Peekable.html#method.next_if
[`Peekable::next_if_eq`]: https://doc.rust-lang.org/nightly/std/iter/struct.Peekable.html#method.next_if_eq
[`VecDeque::range`]: https://doc.rust-lang.org/nightly/std/collections/struct.VecDeque.html#method.range
[`VecDeque::range_mut`]: https://doc.rust-lang.org/nightly/std/collections/struct.VecDeque.html#method.range_mut
ehuss pushed a commit to ehuss/rust that referenced this pull request Jan 8, 2022
Previously suggested in rust-lang/rfcs#2854.

It makes sense to have this since `char` implements `From<u8>`. Likewise
`u32`, `u64`, and `u128` (since rust-lang#79502) implement `From<char>`.
ehuss added a commit to ehuss/rust that referenced this pull request Jan 8, 2022
Implement `TryFrom<char>` for `u8`

Previously suggested in rust-lang/rfcs#2854.

It makes sense to have this since `char` implements `From<u8>`. Likewise `u32`, `u64`, and `u128` (since rust-lang#79502) implement `From<char>`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.