Replace `_, _` with `..` in patterns
This is how https://github.com/rust-lang/rust/issues/33627 looks in action.
Looks especially nice in leftmost/rightmost positions `(first, ..)`/`(.., last)`.
I haven't touched libsyntax intentionally because the feature is still unstable.
add mips64-gnu and mips64el-gnu targets
With this commit one can build no_core (and probably no_std as well)
Rust programs for these targets. It's not yet possible to cross compile
std for these targets because rust-lang/libc doesn't know about the
mips64 architecture.
These targets have been tested by cross compiling the "smallest hello"
program (see code below) and then running it under QEMU.
``` rust
extern {
fn puts(_: *const u8);
}
fn start(_: isize, _: *const *const u8) -> isize {
unsafe {
let msg = b"Hello, world!\0";
puts(msg as *const _ as *const u8);
}
0
}
trait Copy {}
trait Sized {}
```
cc #36015
r? @alexcrichton
cc @brson
The cabi stuff is likely wrong. I just copied cabi_mips source and changed some `4`s to `8`s and `32`s to `64`s. It was enough to get libc's `puts` to work but I'd like someone familiar with this module to check it.
Implement std::convert traits for char
This is motivated by avoiding the `as` operator, which sometimes silently truncates, and instead use conversions that are explicitly lossless and infallible.
I’m less certain that `From<u8> for char` should be implemented: while it matches an existing behavior of `as`, it’s not necessarily the right thing to use for non-ASCII bytes. It effectively decodes bytes as ISO/IEC 8859-1 (since Unicode designed its first 256 code points to be compatible with that encoding), but that is not apparent in the API name.
Use monotonic time in condition variables.
Configure condition variables to use monotonic time using
pthread_condattr_setclock on systems where this is possible.
This fixes the issue when thread waiting on condition variable is
woken up too late when system time is moved backwards.
This turns `..` into `::`, handles some more escapes and gets rid of
unwanted underscores at the beginning of path elements.
memrchr: Correct aligned offset computation
The memrchr fallback did not compute the offset correctly. It was
intentioned to land on usize-aligned addresses but did not.
This was suspected to have resulted in a crash on ARMv7!
This bug affected non-linux platforms.
I think like this, if we have a slice with pointer `ptr` and length
`len`, we want to find the last usize-aligned offset in the slice.
The correct computation should be:
For example if ptr = 1 and len = 6, and `size_of::<usize>()` is 4:
```
[ x x x x x x ]
1 2 3 4 5 6
^-- last aligned address at offset 3 from the start.
```
The last aligned address is ptr + len - (ptr + len) % usize_size.
Compute offset from the start as:
offset = len - (ptr + len) % usize_size = 6 - (1 + 6) % 4 = 6 - 3 = 3.
I believe the function's return value was always correct previously, if
the platform supported unaligned addresses.
Fixes#35967
Use arc4rand(9) on FreeBSD
From rust-lang-nursery/rand#112:
>After reading through #30691 it seems that there's general agreement that using OS-provided facilities for seeding rust userland processes is fine as long as it doesn't use too much from libc. FreeBSD's `arc4random_buf(3)` is not only a whole lot of libc code, but also not even currently exposed in the libc crate. Fortunately, the mechanism `arc4random_buf(3)` et al. use for getting entropy from the kernel ([`arc4rand(9)`](https://www.freebsd.org/cgi/man.cgi?query=arc4random&apropos=0&sektion=9&manpath=FreeBSD+10.3-RELEASE&arch=default&format=html)) is exposed via `sysctl(3)` with constants that are already in the libc crate.
>I haven't found too much documentation on `KERN_ARND`—it's missing or only briefly described in most of the places that cover sysctl mibs. But, from digging through the kernel source, it appears that the sysctl used in this PR is very close to just calling `arc4rand(9)` directly (with `reseed` set to 0 and no way to change it).
I expected [rand](/rust-lang-nursery/rand) to reply quicker, so I tried submitting it there first. It's been a few weeks with no comment, so I don't know the state of it, but maybe someone will see it here and have an opinion. This is basically the same patch. It pains me to duplicate the code but I guess it hasn't been factored out into just one place yet.
The memrchr fallback did not compute the offset correctly. It was
intentioned to land on usize-aligned addresses but did not.
This was suspected to resulted in a crash on ARMv7 platform!
This bug affected non-linux platforms.
I think like this, if we have a slice with pointer `ptr` and length
`len`, we want to find the last usize-aligned offset in the slice.
The correct computation should be:
For example if ptr = 1 and len = 6, and size_of::<usize>() is 4:
[ x x x x x x ]
1 2 3 4 5 6
^-- last aligned address at offset 3 from the start.
The last aligned address is ptr + len - (ptr + len) % usize_size.
Compute offset from the start as:
offset = len - (ptr + len) % usize_size = 6 - (1 + 6) % 4 = 6 - 3 = 3.
I believe the function's return value was always correct previously, if
the platform supported unaligned addresses.
Implement 1581 (FusedIterator)
* [ ] Implement on patterns. See https://github.com/rust-lang/rust/issues/27721#issuecomment-239638642.
* [ ] Handle OS Iterators. A bunch of iterators (`Args`, `Env`, etc.) in libstd wrap platform specific iterators. The current ones all appear to be well-behaved but can we assume that future ones will be?
* [ ] Does someone want to audit this? On first glance, all of the iterators on which I implemented `FusedIterator` appear to be well-behaved but there are a *lot* of them so a second pair of eyes would be nice.
* I haven't touched rustc internal iterators (or the internal rand) because rustc doesn't actually call `fuse()`.
* `FusedIterator` can't be implemented on `std::io::{Bytes, Chars}`.
Closes: #35602 (Tracking Issue)
Implements: rust-lang/rfcs#1581
cstring: avoid excessive growth just to 0-terminate
Based on following what happens in CString::new("string literal"):
1. Using `Into<Vec<u8>>`, a Vec is allocated with capacity exactly equal
to the string's input length.
2. By `v.push(0)`, the Vec is grown to twice capacity, since it was full.
3. By `v.into_boxed_slice()`, the Vec capacity is shrunk to fit the length again.
If we use `.reserve_exact(1)` just before the push, then we avoid the
capacity doubling that we're going to have to shrink anyway.
Growing by just 1 byte means that the step (2) is less likely to have to
move the memory to a larger allocation chunk, and that the step (3) does
not have to reallocate.
Addresses part of #35838
Based on following what happens in CString::new("string literal"):
1. Using `Into<Vec<u8>>`, a Vec is allocated with capacity exactly equal
to the string's input length.
2. By `v.push(0)`, the Vec is grown to twice capacity, since it was full.
3. By `v.into_boxed_slice()`, the Vec capacity is shrunk to fit the length again.
If we use `.reserve_exact(1)` just before the push, then we avoid the
capacity doubling that we're going to have to shrink anyway.
Growing by just 1 byte means that the step (2) is less likely to have to
move the memory to a larger allocation chunk, and that the step (3) does
not have to reallocate.
rustdoc: remove the `!` from macro URLs and titles
Because the `!` is part of a macro use, not the macro's name. E.g., you write `macro_rules! foo` not `macro_rules! foo!`, also `#[macro_import(foo)]`.
(Pulled out of #35020).
provide additional justification for array interface design
Explain why Rust does not implement traits for large arrays.
Explain why most methods are implemented on slices rather than arrays.
Note: I'm dipping my toes in the water with a tiny PR. Especially looking for feedback on wording and style. Points of concern: appropriate level of top-level explanation; foreshadowing (is it appropriate to imply that we expect Rust's type system to eventually support size-generic arrays?); using `Foo` and `Bar` as type variables instead of e.g. `T` and `S`.
@peschkaj
Add note to docs for &str that example is to demo internals only
r? @steveklabnik
This adds a note below the &str representation example explaining that the example provided should not be used under normal circumstances..
Would it make sense to point people in the direction of the method(s) they should use instead? I left it out in the interest of not complicating the documentation, but, there's definitely an argument to be made for adding a bit of guidance in there.
Emscripten test fixes
This picks up parts of #31623 to disable certain tests that emscripten can't run, as threads/processes are not supported.
I re-applied @tomaka's changes manually, I can rebase those commits with his credentials if he wants.
It also disables jemalloc for emscripten (at least in Rustbuild, I have to check if there is another setting for the same thing in the old makefile approach).
This should not impact anything for normal builds.
std: Optimize panic::catch_unwind slightly
The previous implementation of this function was overly conservative with
liberal usage of `Option` and `.unwrap()` which in theory never triggers. This
commit essentially removes the `Option`s in favor of unsafe implementations,
improving the code generation of the fast path for LLVM to see through what's
happening more clearly.
cc #34727
The previous implementation of this function was overly conservative with
liberal usage of `Option` and `.unwrap()` which in theory never triggers. This
commit essentially removes the `Option`s in favor of unsafe implementations,
improving the code generation of the fast path for LLVM to see through what's
happening more clearly.
cc #34727
Update HashMap docs regarding DoS protection
Because of changes to how Rust acquires randomness HashMap is not
guaranteed to be DoS resistant. This commit reflects these changes in
the docs themselves and provides an alternative method to creating
a hash that is resistant if needed.
This fixes#33817 and includes relevant information regarding changes made in #33086
Fix build on DragonFly (unused function errno_location)
Function errno_location() is not used on DragonFly. As warnings are
errors, this breaks the build.
Handle RwLock reader count overflow
`pthread_rwlock_rdlock` may return `EAGAIN` if the maximum reader count overflows. We shouldn't return a successful lock in that case.
Because of changes to how Rust acquires randomness HashMap is not
guaranteed to be DoS resistant. This commit reflects these changes in
the docs themselves and provides an alternative method to creating
a hash that is resistant if needed.
