Use raw pointer casts for slice, str's .as_ptr()
We can now use raw pointer casts `*const [T] as *const T` and
`*const str as *const u8` instead of .repr() for getting the
pointer out of a slice.
Was getting error:
```
running: "sh" "/home/flubba86/rust/src/libstd/../libbacktrace/configure" "--with-pic" "--disable-multilib" "--disable-shared" "--disable-host-shared" "--host=asmjs-unknown-emscripten" "--build=x86_64-unknown-linux-gnu"
...
Invalid configuration `asmjs-unknown-emscripten': system `emscripten' not recognized
```
This commit adds the emscripten target to the libbacktrace configure script so it is no longer unrecognized.
These types were already `!Sync`, but this improves error messages when they are used in contexts that require `Sync`, aligning them with conventions used with `Rc`, among others.
r? @alexcrichton
Was getting error:
```
running: "sh" "/home/flubba86/rust/src/libstd/../libbacktrace/configure" "--with-pic" "--disable-multilib" "--disable-shared" "--disable-host-shared" "--host=asmjs-unknown-emscripten" "--build=x86_64-unknown-linux-gnu"
...
Invalid configuration `asmjs-unknown-emscripten': system `emscripten' not recognized
```
Undo change to libbacktrace configure script.
Modify libstd build.rs to not build libbacktrace in the case of targeting emscripten.
These types were already `!Sync`, but this improves error messages when
they are used in contexts that require `Sync`, aligning them with
conventions used with `Rc`, among others.
Zeroing on-drop seems to work fine. Still thinking about the best way to approach zeroing on-move.
(based on top of the other drop PR; only the last 2 commits are relevant)
Hello.
Quite a few of the links in the `core` module concerning redirection to additional primitive type documentation are broken. I noticed in #30214 that there seemed to be a consensus with linking across to `std` module documentation from the `core` module. This is what I've done with the `core` modules for primitive types.
If the changes here are good to go forward with, I'll happily tend to adding more documentation links for the extension traits in the aforementioned issue if need be.
r? @steveklabnik
Use unordered nested list for stabilised APIs to improve readability. This makes the release notes for 1.7 a bit longer, but I don't think we should optimise for brevity here. It's a bit inconsistent since the other releases are not done this way, so feel free to ignore this change.
Also:
- Add link to `u32::checked_neg`
- Remove trailing back tick from BTreeMap line
r? @brson
The default implementations (with `where Self: Sized`) are so that methods that take `self` by value can exist in a trait that’s implemented for dynamically-sized types (`str` and `[u8]`).
CC https://github.com/rust-lang/rust/issues/27809#issuecomment-177564950
CC @alexcrichton
This commit implements documentation generation of the nomicon, the book, the
style guide, and the standalone docs. New steps were added for each one as well
as appropriate makefile targets for each one as well.
These commits add support to the rustbuild build system to compile non-build-system compilers. For example this will allow creating an ARM compiler on a x86 system. The high level way this works is:
* The only compiler ever run is the build target compiler. No other compiler is assumed to be runnable.
* As a result, all output artifacts come from the build compiler.
* The libs for the stageN cross-compiled compiler will be linked into place after the build target builds them.
This will break the assumption that a compiler never links to anything it didn't itself produce, but it retains the assumption that a compiler only ever links to anything built in the same stage. I believe this means that the stage1 cross-compiled compilers will still be usable.
I tested this by creating an `arm-unknown-linux-gnueabihf` compiler. So far the linking ended up all working OK (including LLVM being cross compiled), but I haven't been able to run it yet (in QEMU for a raspberry pi). I think that's because my system linker is messed up or something like that (some newer option is assumed when it's not actually there).
Overall, though, this means that rustbuild can compile an arm-unknown-linux-gnueabihf compiler. Ideally we could even start shipping nightlies based on this at some point!
This commit is the result of the FCPs ending for the 1.8 release cycle for both
the libs and the lang suteams. The full list of changes are:
Stabilized
* `braced_empty_structs`
* `augmented_assignments`
* `str::encode_utf16` - renamed from `utf16_units`
* `str::EncodeUtf16` - renamed from `Utf16Units`
* `Ref::map`
* `RefMut::map`
* `ptr::drop_in_place`
* `time::Instant`
* `time::SystemTime`
* `{Instant,SystemTime}::now`
* `{Instant,SystemTime}::duration_since` - renamed from `duration_from_earlier`
* `{Instant,SystemTime}::elapsed`
* Various `Add`/`Sub` impls for `Time` and `SystemTime`
* `SystemTimeError`
* `SystemTimeError::duration`
* Various impls for `SystemTimeError`
* `UNIX_EPOCH`
* `ops::{Add,Sub,Mul,Div,Rem,BitAnd,BitOr,BitXor,Shl,Shr}Assign`
Deprecated
* Scoped TLS (the `scoped_thread_local!` macro)
* `Ref::filter_map`
* `RefMut::filter_map`
* `RwLockReadGuard::map`
* `RwLockWriteGuard::map`
* `Condvar::wait_timeout_with`
Closes#27714Closes#27715Closes#27746Closes#27748Closes#27908Closes#29866Closes#28235Closes#29720
This applies the same fix as added in 595d5b2f which is to just compile all
valgrind tests statically instead of dynamically. It looks like this is a
resurgence of either #30383 or #31328 in some weird fashion.
I'm not actually sure what's going on with the bots, and it's unclear whether
this is a valgrind bug or a libstd bug, but for now let's just get things
landing again.
Closes#30383
This commit is the result of the FCPs ending for the 1.8 release cycle for both
the libs and the lang suteams. The full list of changes are:
Stabilized
* `braced_empty_structs`
* `augmented_assignments`
* `str::encode_utf16` - renamed from `utf16_units`
* `str::EncodeUtf16` - renamed from `Utf16Units`
* `Ref::map`
* `RefMut::map`
* `ptr::drop_in_place`
* `time::Instant`
* `time::SystemTime`
* `{Instant,SystemTime}::now`
* `{Instant,SystemTime}::duration_since` - renamed from `duration_from_earlier`
* `{Instant,SystemTime}::elapsed`
* Various `Add`/`Sub` impls for `Time` and `SystemTime`
* `SystemTimeError`
* `SystemTimeError::duration`
* Various impls for `SystemTimeError`
* `UNIX_EPOCH`
* `ops::{Add,Sub,Mul,Div,Rem,BitAnd,BitOr,BitXor,Shl,Shr}Assign`
Deprecated
* Scoped TLS (the `scoped_thread_local!` macro)
* `Ref::filter_map`
* `RefMut::filter_map`
* `RwLockReadGuard::map`
* `RwLockWriteGuard::map`
* `Condvar::wait_timeout_with`
Closes#27714Closes#27715Closes#27746Closes#27748Closes#27908Closes#29866
When cross compiling for a new host, we can't actually run the host compiler to
generate its own libs. In theory, however, all stage2 compilers (for any host)
will produce the same libraries, so we just require the build compiler to
produce the necessary host libraries and then we link those into place.
