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
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)
This commit updates the OS random number generator on Windows to match the
upstream implementation in the `rand` crate. First proposed in
rust-lang-nursery/rand#111 this implementation uses a "private" API of
`RtlGenRandom`. Despite the [documentation][dox] indicating this is a private
function its widespread use in Chromium and Firefox as well as [comments] from
Microsoft internally indicates that it's highly unlikely to break.
Another motivation for switching this is to also attempt to make progress
on #44911. It may be the case that this function succeeds while the previous
implementation may fail in "weird" scenarios.
[dox]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694(v=vs.85).aspx
[comments]: https://github.com/rust-lang-nursery/rand/issues/111#issuecomment-316140155
Linux appears to set POLLOUT when a conection's refused, which is pretty
weird. Invert the check to look for an error explicitly. Also add an
explict test for this case.
Closes#45265.
Remove support for the PNaCl target (le32-unknown-nacl)
This removes support for the `le32-unknown-nacl` target which is currently supported by rustc on tier 3. Despite the "nacl" in the name, the target doesn't output native code (x86, ARM, MIPS), instead it outputs binaries in the PNaCl format.
There are two reasons for the removal:
* Google [has announced](https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html) deprecation of the PNaCl format. The suggestion is to migrate to wasm. Happens we already have a wasm backend!
* Our PNaCl LLVM backend is provided by the fastcomp patch set that the LLVM fork used by rustc contains in addition to vanilla LLVM (`src/llvm/lib/Target/JSBackend/NaCl`). Upstream LLVM doesn't have PNaCl support. Removing PNaCl support will enable us to move away from fastcomp (#44006) and have a lighter set of patches on top of upstream LLVM inside our LLVM fork. This will help distribution packagers of Rust.
Fixes#42420
zircon: the type of zx_handle_t is now unsigned
This is a kernel ABI change that landed today. I noticed some other ABI
issues and have left a note to cleanup once they are better defined.
The previous workaround for gibc's res_init bug is not thread-safe on
other implementations of libc, and it can cause crashes. Use a runtime
check to make sure we only call res_init when we need to, which is also
when it's safe. See https://github.com/rust-lang/rust/issues/43592.
* Use size_t where size_t is used, while it's not critical on our
specifically supported architectures, this is more accurate.
* Update HND_SPECIAL_COUNT to the correct value, and give it the size
that enum is likely to be.
make `backtrace = false` compile for windows targets.
when building for windows with `backtrace = false`, `libstd` fails to compile because some modules that use items from `sys_common::backtrace::*` are still included, even though those modules aren't used or referenced by anything.
`sys_common::backtrace` doesn't exist when the backtrace feature is turned off.
--
i've also added `#[cfg(feature = "backtrace")]` to various items that exist exclusively to support `mod backtrace` since the compilation would fail since they would be unused in a configuration with backtraces turned off.
On Windows with the NTFS filesystem, `fs::copy` would return the sum of the
lengths of all streams, which can be different from the length reported by
`metadata` and thus confusing for users unaware of this NTFS peculiarity.
This makes `fs::copy` return the same length `metadata` reports which is the
value it used to return before PR #26751. Note that alternate streams are still
copied; their length is just not included in the returned value.
This change relies on the assumption that the stream with index 1 is always the
main stream in the `CopyFileEx` callback. I could not find any official
document confirming this but empirical testing has shown this to be true,
regardless of whether the alternate stream is created before or after the main
stream.
Resolves#44532
Retain suid/sgid/sticky bits in Metadata.permissions
Most users would expect set_permissions(Metadata.permissions()) to be
non-destructive. While we can't guarantee this, we can at least pass
the needed info to chmod.
Also update the PermissionsExt documentation to disambiguate what it
contains, and to refer to the underlying value as `st_mode` rather than
its type `mode_t`.
Closes#44147
Most users would expect set_permissions(Metadata.permissions()) to be
non-destructive. While we can't guarantee this, we can at least pass
the needed info to chmod.
Also update the PermissionsExt documentation to disambiguate what it
contains, and to refer to the underlying value as `st_mode` rather than
its type `mode_t`.
Closes#44147
Add the libstd-modifications needed for the L4Re target
This commit adds the needed modifications to compile the std crate for the L4 Runtime environment (L4Re).
A target for the L4Re was introduced in commit: c151220a84
In many aspects implementations for linux also apply for the L4Re microkernel.
Some uncommon characteristics had to be resolved:
* L4Re has no network funktionality
* L4Re has a maximum stacksize of 1Mb for threads
* L4Re has no uid or gid
Co-authored-by: Sebastian Humenda <sebastian.humenda@tu-dresden.de>
Properly detect overflow in Instance ± Duration.
Fix#44216.
Fix#42622
The computation `Instant::now() + Duration::from_secs(u64::max_value())` now panics. The call `receiver.recv_timeout(Duration::from_secs(u64::max_value()))`, which involves such time addition, will also panic.
The reason #44216 arises is because of an unchecked cast from `u64` to `i64`, making the duration equivalent to -1 second.
Note that the current implementation is over-conservative, since e.g. (-2⁶²) + (2⁶³) is perfectly fine for an `i64`, yet this is rejected because (2⁶³) overflows the `i64`.
As suggested in the discussion of PR #43972, std should provide a uniform API to
all platforms. Since there's no networking on L4Re, this now is a module in
`sys::net` providing types and functions/methods returning an error for each
action.
This commit adds the needed modifications to compile the std crate
for the L4 Runtime environment (L4Re).
A target for the L4Re was introduced in commit:
c151220a84
In many aspects implementations for linux also apply for the L4Re
microkernel.
Two uncommon characteristics had to be resolved:
* L4Re has no network funktionality
* L4Re has a maximum stacksize of 1Mb for threads
Co-authored-by: Sebastian Humenda <sebastian.humenda@tu-dresden.de>
* Match definition of c_char in os/raw.rs with the libc definition
Due to historic reasons, os/raw.rs redefines types for c_char from
libc, but these didn't match. Now they do :).
* Enable signal reset on exec for L4Re
L4Re has full signal emulation and hence it needs to reset the
signal set of the child with sigemptyset. However, gid and uid
should *not* be set.
