This commit renames the `replace` function to `replace_entry`, and
creates a seperate `replace_key` function for `OccupiedEntry`. The
original `replace` function did not solve the use-case where the
key needed to be replaced, but not the value. Documentation and
naming has also been updated to better reflect what the original
replace function does.
This commit removes usage of the `libc` crate in "portable" modules like
those at the top level and `sys_common`. Instead common types like `*mut
u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as
switching to platform-specific functions like `sys::strlen` instead of
`libc::strlen`.
This commit moves the `f32::cmath` and `f64::cmath` modules into the
`sys` module. Note that these are not publicly exported modules, simply
implementation details. These modules are already platform-specific with
shims on MSVC and this is mostly just a reflection of that reality. This
should also help cut down on `#[cfg]` traffic if platforms are brought on
which don't directly support these functions.
This commit removes the reexport of `EBADF_ERR` as a constant from
libstd's portability facade, instead opting for a platform-specific
function that specifically queries an `io::Error`. Not all platforms may
have a constant for this, so it makes the intent a little more clear
that a code need not be supplied, just an answer to a query.
This commit removes the `rand` crate from the standard library facade as
well as the `__rand` module in the standard library. Neither of these
were used in any meaningful way in the standard library itself. The only
need for randomness in libstd is to initialize the thread-local keys of
a `HashMap`, and that unconditionally used `OsRng` defined in the
standard library anyway.
The cruft of the `rand` crate and the extra `rand` support in the
standard library makes libstd slightly more difficult to port to new
platforms, namely WebAssembly which doesn't have any randomness at all
(without interfacing with JS). The purpose of this commit is to clarify
and streamline randomness in libstd, focusing on how it's only required
in one location, hashmap seeds.
Note that the `rand` crate out of tree has almost always been a drop-in
replacement for the `rand` crate in-tree, so any usage (accidental or
purposeful) of the crate in-tree should switch to the `rand` crate on
crates.io. This then also has the further benefit of avoiding
duplication (mostly) between the two crates!
Warn about lack of args glob expansion in Windows shell
Because all shells on Linux/macOS expand globs, and even MinGW on Windows emulates this behavior, it's easy to forget that Windows by itself doesn't support glob expansion. This PR documents this cross-platform difference.
RwLock guards are Sync if T is
Currently, the compiler requires `T` to also be `Send`. There is no reason for
that. `&Rw{Read,Write}LockGuard` only provides a shared referenced to `T`, sending
that across threads is safe if `T` is `Sync`.
Cc @oconnor663
Implement is_empty() for BufReader
Simple implementation of `is_empty` method for BufReader so it is possible to tell whether there is any data in its buffer.
I didn't know correct stability annotation to place on the function. Presumably there is no reason to place this feature behind a feature flag, but I wasn't sure how to tag it as an unstable feature without that.
CC: #45323
Copy all `AsciiExt` methods to the primitive types directly in order to deprecate it later
**EDIT:** [this PR is ready now](https://github.com/rust-lang/rust/pull/44042#issuecomment-333883548). I edited this post to reflect the current status of discussion, which is (apart from code review) pretty much settled.
---
This is my current progress in order to prepare stabilization of #39658. As discussed there (and in #39659), the idea is to deprecated `AsciiExt` and copy all methods to the type directly. Apparently there isn't really a reason to have those methods in an extension trait¹.
~~This is **work in progress**: copy&pasting code while slightly modifying the documentation isn't the most exciting thing to do. Therefore I wanted to already open this WIP PR after doing basically 1/4 of the job (copying methods to `&[u8]`, `char` and `&str` is still missing) to get some feedback before I continue. Some questions possibly worth discussing:~~
1. ~~Does everyone agree that deprecating `AsciiExt` is a good idea? Does everyone agree with the goal of this PR?~~ => apparently yes
2. ~~Are my changes OK so far? Did I do something wrong?~~
3. ~~The issue of the unstable-attribute is currently set to 0. I would wait until you say "Ok" to the whole thing, then create a tracking issue and then insert the correct issue id. Is that ok?~~
4. ~~I tweaked `eq_ignore_ascii_case()`: it now takes the argument `other: u8` instead of `other: &u8`. The latter was enforced by the trait. Since we're not bound to a trait anymore, we can drop the reference, ok?~~ => I reverted this, because the interface has to match the `AsciiExt` interface exactly.
¹ ~~Could it be that we can't write `impl [u8] {}`? This might be the reason for `AsciiExt`. If that is the case: is there a good reason we can't write such an impl block? What can we do instead?~~ => we couldn't at the time this PR was opened, but Simon made it possible.
/cc @SimonSapin @zackw
Right now symbol exports, particularly in a cdylib, are handled by
assuming that `pub extern` combined with `#[no_mangle]` means "export
this". This isn't actually what we want for some symbols that the
standard library uses to implement itself, for example symbols related
to allocation. Additionally other special symbols like
`rust_eh_personallity` have no need to be exported from cdylib crate
types (only needed in dylib crate types).
This commit updates how rustc handles these special symbols by adding to
the hardcoded logic of symbols like `rust_eh_personallity` but also
adding a new attribute, `#[rustc_std_internal_symbol]`, which forces the
export level to be considered the same as all other Rust functions
instead of looking like a C function.
The eventual goal here is to prevent functions like `__rdl_alloc` from
showing up as part of a Rust cdylib as it's just an internal
implementation detail. This then further allows such symbols to get gc'd
by the linker when creating a cdylib.
Fix libstd compile error for windows-gnu targets without `backtrace`
This is basically an addition to #44979. Compiling `libstd` still fails when targeting `windows-gnu` with `panic = "abort"` because the items in the `...c::gnu` module are not used. They are only referenced from `backtrace_gnu.rs`, which is indirectly feature gated behind `backtrace` [here](9f3b09116b/src/libstd/sys/windows/mod.rs (L23)).
We don't want to stabilize them now already. The goal of this set of
commits is just to add inherent methods to the four types. Stabilizing
all of those methods can be done later.
Many AsciiExt imports have become useless thanks to the inherent ascii
methods added in the last commits. These were removed. In some places, I
fully specified the ascii method being called to enforce usage of the
AsciiExt trait. Note that some imports are not removed but tagged with
a `#[cfg(stage0)]` attribute. This is necessary, because certain ascii
methods are not yet available in stage0. All those imports will be
removed later.
Additionally, failing tests were fixed. The test suite should exit
successfully now.
This is done in order to deprecate AsciiExt eventually. Note that
this commit contains a bunch of `cfg(stage0)` statements. This is
due to a new compiler feature this commit depends on: the
`slice_u8` lang item. Once this lang item is available in the
stage0 compiler, all those cfg flags (and more) can be removed.
This is done in order to deprecate AsciiExt eventually. Note that
this commit contains a bunch of `cfg(stage0)` statements. This is
due to a new compiler feature I am using: the `slice_u8` lang item.
Once this lang item is available in the stage0 compiler, all those
cfg flags (and more) can be removed.
The doc comments were incorrect before: since the inherent ascii methods
shadow the `AsciiExt` methods, the examples didn't use the `AsciiExt` at
all. Since the trait will be deprecated soon anyway, the easiest solution
was to remove the examples and already mention that the methods will be
deprecated in the near future.
Since the methods on u8 directly will shadow the AsciiExt methods,
we cannot change the signature without breaking everything. It
would have been nice to take `u8` as argument instead of `&u8`, but
we cannot break stuff! So this commit reverts it to the original
`&u8` version.
This is the first step in order to deprecate AsciiExt. Since
this is a WIP commit, there is still some code duplication (notably
the static arrays) that will be removed later.
Currently, the compiler requires `T` to also be `Send`. There is no reason for
that. `&Rw{Read,Write}LockGuard` only provides a shared referenced to `T`, sending
that across threads is safe if `T` is `Sync`.
More fixes for x86_64-unknown-linux-gnux32
This update libc (all libc testing are passing) and fixes NR_GETRANDOM.
Fix all but one run-pass test (lto-unwind.rs, see https://github.com/rust-lang/rust/issues/45416)
remove the `T: Sync` requirement for `RwLock<T>: Send`
That requirement makes sense for containers like `Arc` that don't
uniquely own their contents, but `RwLock` is not one of those.
This restriction was added in 380d23b5d4, but it's not clear why. @hniksic
and I [were discussing this on reddit](https://www.reddit.com/r/rust/comments/763o7r/blog_posts_introducing_lockfree_rust_comparing/dobcvbm/). I might be totally wrong about this change being sound, but I'm super curious to find out :)
Implement TryFrom<&[T]> for &[T; N]
There are many cases where a buffer with a static compile-time size is preferred over a slice with a dynamic size. This allows for performing a checked conversion from `&[T]` to `&[T; N]`. This may also lead to compile-time optimizations involving `[T; N]` such as loop unrolling.
This is my first PR to Rust, so I'm not sure if discussion of this change should happen here or does it need its own RFC? I figured these changes would be a subset of #33417.
