-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Tracking issue for std::dynamic_lib #27810
Comments
|
Yeah if we remove from the standard library I'd definitely at least want an external crate with this functionality. That being said the standard library does indeed use this as an implementation detail for various aspects, so that may be a good indicator that it should be in libstd to begin with. |
I so far found a several problems with the API exposed currently: Some of the exposed methods are not cross-platform or might not do what’s intended. Most notably the methods dealing with search pathes… On Windows it doesn’t use AddDllDirectory/SetDllDirectory and manipulates environment instead. Man pages claim that on unix
Publicly exposed Finally, I feel like there should be a simple way to prevent using symbols after the library is dropped, by e.g. returning |
FWIW there is a crate which is just a copy of the unstable API from libstd, and if the crates.io download count is to be believed it has rather widespread usage. |
It seems like we should probably be deprecating and removing the in-tree version of this. The API's pretty bad right now and improvements should probably be prototyped out of tree. |
I’m experimenting with various options on my free time: libloading |
This issue is now entering its cycle-long FCP for deprecation in 1.5 |
There is also the shared_library crate. Would be good to offer an recommended alternative in the compiler message. |
Really seems like a systems language should have this in std. (I realize we There is also the shared_library https://crates.io/crates/shared_library Would be good to offer an recommended alternative in the compiler message. — |
For Win32 and Win64, all normal pointers are interchangeable, so both function and data pointers can be retrieved fine. Far and near only mattered in the times of Win16. |
The libs team discussed this today and the decision was to deprecate. |
This commit stabilizes and deprecates library APIs whose FCP has closed in the last cycle, specifically: Stabilized APIs: * `fs::canonicalize` * `Path::{metadata, symlink_metadata, canonicalize, read_link, read_dir, exists, is_file, is_dir}` - all moved to inherent methods from the `PathExt` trait. * `Formatter::fill` * `Formatter::width` * `Formatter::precision` * `Formatter::sign_plus` * `Formatter::sign_minus` * `Formatter::alternate` * `Formatter::sign_aware_zero_pad` * `string::ParseError` * `Utf8Error::valid_up_to` * `Iterator::{cmp, partial_cmp, eq, ne, lt, le, gt, ge}` * `<[T]>::split_{first,last}{,_mut}` * `Condvar::wait_timeout` - note that `wait_timeout_ms` is not yet deprecated but will be once 1.5 is released. * `str::{R,}MatchIndices` * `str::{r,}match_indices` * `char::from_u32_unchecked` * `VecDeque::insert` * `VecDeque::shrink_to_fit` * `VecDeque::as_slices` * `VecDeque::as_mut_slices` * `VecDeque::swap_remove_front` - (renamed from `swap_front_remove`) * `VecDeque::swap_remove_back` - (renamed from `swap_back_remove`) * `Vec::resize` * `str::slice_mut_unchecked` * `FileTypeExt` * `FileTypeExt::{is_block_device, is_char_device, is_fifo, is_socket}` * `BinaryHeap::from` - `from_vec` deprecated in favor of this * `BinaryHeap::into_vec` - plus a `Into` impl * `BinaryHeap::into_sorted_vec` Deprecated APIs * `slice::ref_slice` * `slice::mut_ref_slice` * `iter::{range_inclusive, RangeInclusive}` * `std::dynamic_lib` Closes rust-lang#27706 Closes rust-lang#27725 cc rust-lang#27726 (align not stabilized yet) Closes rust-lang#27734 Closes rust-lang#27737 Closes rust-lang#27742 Closes rust-lang#27743 Closes rust-lang#27772 Closes rust-lang#27774 Closes rust-lang#27777 Closes rust-lang#27781 cc rust-lang#27788 (a few remaining methods though) Closes rust-lang#27790 Closes rust-lang#27793 Closes rust-lang#27796 Closes rust-lang#27810 cc rust-lang#28147 (not all parts stabilized)
This commit stabilizes and deprecates library APIs whose FCP has closed in the last cycle, specifically: Stabilized APIs: * `fs::canonicalize` * `Path::{metadata, symlink_metadata, canonicalize, read_link, read_dir, exists, is_file, is_dir}` - all moved to inherent methods from the `PathExt` trait. * `Formatter::fill` * `Formatter::width` * `Formatter::precision` * `Formatter::sign_plus` * `Formatter::sign_minus` * `Formatter::alternate` * `Formatter::sign_aware_zero_pad` * `string::ParseError` * `Utf8Error::valid_up_to` * `Iterator::{cmp, partial_cmp, eq, ne, lt, le, gt, ge}` * `<[T]>::split_{first,last}{,_mut}` * `Condvar::wait_timeout` - note that `wait_timeout_ms` is not yet deprecated but will be once 1.5 is released. * `str::{R,}MatchIndices` * `str::{r,}match_indices` * `char::from_u32_unchecked` * `VecDeque::insert` * `VecDeque::shrink_to_fit` * `VecDeque::as_slices` * `VecDeque::as_mut_slices` * `VecDeque::swap_remove_front` - (renamed from `swap_front_remove`) * `VecDeque::swap_remove_back` - (renamed from `swap_back_remove`) * `Vec::resize` * `str::slice_mut_unchecked` * `FileTypeExt` * `FileTypeExt::{is_block_device, is_char_device, is_fifo, is_socket}` * `BinaryHeap::from` - `from_vec` deprecated in favor of this * `BinaryHeap::into_vec` - plus a `Into` impl * `BinaryHeap::into_sorted_vec` Deprecated APIs * `slice::ref_slice` * `slice::mut_ref_slice` * `iter::{range_inclusive, RangeInclusive}` * `std::dynamic_lib` Closes #27706 Closes #27725 cc #27726 (align not stabilized yet) Closes #27734 Closes #27737 Closes #27742 Closes #27743 Closes #27772 Closes #27774 Closes #27777 Closes #27781 cc #27788 (a few remaining methods though) Closes #27790 Closes #27793 Closes #27796 Closes #27810 cc #28147 (not all parts stabilized)
For reference - |
It was deprecated in 1.5. |
This is a tracking issue for the unstable
dynamic_lib
feature of the standard library. This module should probably just be made private to the standard library and the compiler rather than being exported for now. A future RFC could decide whether it should be a module in the standard library or not.The text was updated successfully, but these errors were encountered: