Add NumCast trait for generic numeric type casts #4881
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bors
added a commit
that referenced
this pull request
Feb 13, 2013
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 2, 2020
…take, r=flip1995 Use `mem::take` instead of `mem::replace` when applicable `std::mem::take` can be used to replace a value of type `T` with `T::default()` instead of `std::mem::replace`. Fixes issue rust-lang#4871 changelog: Added lint for [`mem_replace_with_default`]
This was referenced Aug 16, 2022
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Aug 20, 2022
Revert "Revert "Allow dynamic linking for iOS/tvOS targets."" This reverts commit 16e10bf (PR rust-lang#77716). The original original PR enabled `cdylib` builds for iOS. However this caused problems because: > This new feature in Rust 1.46 added a lot of headache for iOS builds with cdylib targets. cdylib target is near impossible to build if you are using any crate with native dependencies (ex. openssl, libsodium, zmq). You can't just find .so files for all architectures to perform correct linking. Usual workflow is the following: > > 1. You build staticlib and rely that native dependencies will be linked as frameworks later > 2. You setup right cocoapods in ObjectiveC/Swift wrapper. > > As cargo doesn't support platform-dependent crate types rust-lang#4881 as a result a lot of projects now broken on Rust 1.46 However, this will be soon a thing of the past since 1.64 brings us the long awaited much anticipated `--crate-type` flag. > I see that this got merged recently: rust-lang/cargo#10083. The --crate-type flag will get stabilized in 1.64. In 1.64, you could still get a successful iOS staticlib with cargo build --crate-type=statclib even if the crate has cdylib targets too. If I'm not mistaken, this solves the problem too so this PR could be reverted in 1.64 with relatively little headache. So summing up, I think this PR can be reverted in 1.64. 🤞
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Aug 20, 2022
Revert "Revert "Allow dynamic linking for iOS/tvOS targets."" This reverts commit 16e10bf (PR rust-lang#77716). The original original PR enabled `cdylib` builds for iOS. However this caused problems because: > This new feature in Rust 1.46 added a lot of headache for iOS builds with cdylib targets. cdylib target is near impossible to build if you are using any crate with native dependencies (ex. openssl, libsodium, zmq). You can't just find .so files for all architectures to perform correct linking. Usual workflow is the following: > > 1. You build staticlib and rely that native dependencies will be linked as frameworks later > 2. You setup right cocoapods in ObjectiveC/Swift wrapper. > > As cargo doesn't support platform-dependent crate types rust-lang#4881 as a result a lot of projects now broken on Rust 1.46 However, this will be soon a thing of the past since 1.64 brings us the long awaited much anticipated `--crate-type` flag. > I see that this got merged recently: rust-lang/cargo#10083. The --crate-type flag will get stabilized in 1.64. In 1.64, you could still get a successful iOS staticlib with cargo build --crate-type=statclib even if the crate has cdylib targets too. If I'm not mistaken, this solves the problem too so this PR could be reverted in 1.64 with relatively little headache. So summing up, I think this PR can be reverted in 1.64. 🤞
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Aug 20, 2022
Revert "Revert "Allow dynamic linking for iOS/tvOS targets."" This reverts commit 16e10bf (PR rust-lang#77716). The original original PR enabled `cdylib` builds for iOS. However this caused problems because: > This new feature in Rust 1.46 added a lot of headache for iOS builds with cdylib targets. cdylib target is near impossible to build if you are using any crate with native dependencies (ex. openssl, libsodium, zmq). You can't just find .so files for all architectures to perform correct linking. Usual workflow is the following: > > 1. You build staticlib and rely that native dependencies will be linked as frameworks later > 2. You setup right cocoapods in ObjectiveC/Swift wrapper. > > As cargo doesn't support platform-dependent crate types rust-lang#4881 as a result a lot of projects now broken on Rust 1.46 However, this will be soon a thing of the past since 1.64 brings us the long awaited much anticipated `--crate-type` flag. > I see that this got merged recently: rust-lang/cargo#10083. The --crate-type flag will get stabilized in 1.64. In 1.64, you could still get a successful iOS staticlib with cargo build --crate-type=statclib even if the crate has cdylib targets too. If I'm not mistaken, this solves the problem too so this PR could be reverted in 1.64 with relatively little headache. So summing up, I think this PR can be reverted in 1.64. 🤞
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Aug 20, 2022
Revert "Revert "Allow dynamic linking for iOS/tvOS targets."" This reverts commit 16e10bf (PR rust-lang#77716). The original original PR enabled `cdylib` builds for iOS. However this caused problems because: > This new feature in Rust 1.46 added a lot of headache for iOS builds with cdylib targets. cdylib target is near impossible to build if you are using any crate with native dependencies (ex. openssl, libsodium, zmq). You can't just find .so files for all architectures to perform correct linking. Usual workflow is the following: > > 1. You build staticlib and rely that native dependencies will be linked as frameworks later > 2. You setup right cocoapods in ObjectiveC/Swift wrapper. > > As cargo doesn't support platform-dependent crate types rust-lang#4881 as a result a lot of projects now broken on Rust 1.46 However, this will be soon a thing of the past since 1.64 brings us the long awaited much anticipated `--crate-type` flag. > I see that this got merged recently: rust-lang/cargo#10083. The --crate-type flag will get stabilized in 1.64. In 1.64, you could still get a successful iOS staticlib with cargo build --crate-type=statclib even if the crate has cdylib targets too. If I'm not mistaken, this solves the problem too so this PR could be reverted in 1.64 with relatively little headache. So summing up, I think this PR can be reverted in 1.64. 🤞
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.