`ReadFile` and `WriteFile` take a DWORD (u32) for the length argument
which was erroneously cast from a usize causing truncation. This meant
methods like `write_all` and `read_exact` would unexpectedly fail if
given a buffer 4 GiB or larger.
We can instead just ask for `u32::MAX` bytes if the given buffer is too
big.
The `vfp2` option was a leftover from `armv6` compatibility features of the original armhf target.
Gcc defaults to `vfp3`on `armv7` hard-float linux systems so we should make it the default for rustc too.
`ReadFile` and `WriteFile` take a DWORD (u32) for the length argument
which was erroneously cast from a usize causing truncation. This meant
methods like `write_all` and `read_exact` would unexpectedly fail if
given a buffer 4 GiB or larger.
We can instead just ask for `u32::MAX` bytes if the given buffer is too
big.
Hello.
I came across some minor spelling mistakes while going through the documentation for the `Iterator` trait. Also includes a suggested styling fix.
r? @steveklabnik
Windows is not #[cfg(target_thread_local)] and as such should link
to the external symbol. But it fails with:
thread '<main>' panicked at 'assertion failed: `(left == right)` (left: `272246271`, right: `3`)', C:/bot/slave/auto-win-msvc-64-opt/build/src/test/run-pass/thread-local-extern-static.rs:24
The standard library doesn't depend on rustc_bitflags, so move it to explicit
dependencies on all other crates. Additionally, the arena/fmt_macros deps could
be dropped from libsyntax.
Android should use 64-bit LFS symbols for `lseek` and `ftruncate`, lest
those offset parameters suffer a lossy cast down to a 32-bit `off_t`.
Unlike GNU/Linux, Android's `stat`, `dirent`, and related functions are
always 64-bit LFS compatible, and `open` already implies `O_LARGEFILE`,
so all those don't need to follow Linux. It might be nice to unify them
anyway, but those other LFS symbols aren't present in API 18 bionic.
r? @alexcrichton
Some struct members have a slighty different name on NetBSD. This has been fixed in the libc crate, but not in libstd, breaking the NetBSD build. Related C struct definition: http://nxr.netbsd.org/xref/src/sys/sys/stat.h?r=1.68#59
This also removes the broken `st_spare()` from MetadataExt, since it is private field reserved for future use.
@dhuseby In case this conflicts with any of your pending patches, feel free to intervene - I'm happy to withdraw this PR.
r? @alexcrichton
With these changes you can build a freestanding sysroot without using floating points using a Cargo.toml and copying the `deps` folder cargo outputs.
```
[package]
name = "sysroot"
version = "0.1.0"
[lib]
path = "lib.rs"
crate-type = ["rlib"]
[dependencies.core]
path = "../vendor/rust/src/src/libcore"
features = ["disable_float"]
[dependencies]
collections = { path = "../vendor/rust/src/src/libcollections" }
```
The standard library doesn't depend on rustc_bitflags, so move it to explicit
dependencies on all other crates. Additionally, the arena/fmt_macros deps could
be dropped from libsyntax.
Some struct members have a slighty different name on NetBSD. This has been
fixed in the libc crate, but not in libstd.
This also removes `st_spare` from MetadataExt, since it is private field
reserved for future use.
Android should use 64-bit LFS symbols for `lseek` and `ftruncate`, lest
those offset parameters suffer a lossy cast down to a 32-bit `off_t`.
Unlike GNU/Linux, Android's `stat`, `dirent`, and related functions are
always 64-bit LFS compatible, and `open` already implies `O_LARGEFILE`,
so all those don't need to follow Linux. It might be nice to unify them
anyway, but those other LFS symbols aren't present in API 18 bionic.
r? @alexcrichton
Right now the compiler's we're using actually default to armv7/thumb2 I believe,
so this should help push them back to what the arm-unknown-linux-* targets are
for. This at least matches that clang does for the `arm-unknown-linux-gnueabihf`
target which is to map it to an armv6 architecture.
Closes#31787
Tracking issue: #31756
RFC: rust-lang/rfcs#1467
I've made these unstable for now. Should they be stabilized straight away since we've had plenty of experience with people using the unstable intrinsics?
