Trevor Spiteri [Thu, 30 Jan 2020 14:49:21 +0000 (15:49 +0100)]
rustdoc: attempt full build for compile_fail test
Some code fails when doing a full build but does not fail when only
emitting metadata. This commit makes sure compile_fail tests for such
code behave as expected, that is, the test succeeds because the
compilation fails.
Dylan DPC [Thu, 30 Jan 2020 00:46:42 +0000 (01:46 +0100)]
Rollup merge of #68468 - ssomers:btreemap_prefer_middle, r=Mark-Simulacrum
BTreeMap: tag and explain unsafe internal functions or assert preconditions
#68418 concluded that it's not desirable to tag all internal functions with preconditions as being unsafe. This PR does it to some functions, documents why, and elsewhere enforces the preconditions with asserts.
Dylan DPC [Thu, 30 Jan 2020 00:46:38 +0000 (01:46 +0100)]
Rollup merge of #66648 - crgl:btree-clone-from, r=Amanieu
Implement clone_from for BTreeMap and BTreeSet
See #28481. This results in up to 90% speedups on simple data types when `self` and `other` are the same size, and is generally comparable or faster. Some concerns:
1. This implementation requires an `Ord` bound on the `Clone` implementation for `BTreeMap` and `BTreeSet`. Since these structs can only be created externally for keys with `Ord` implemented, this should be fine? If not, there's certainly a less safe way to do this.
2. Changing `next_unchecked` on `RangeMut` to return mutable key references allows for replacing the entire overlapping portion of both maps without changing the external interface in any way. However, if `clone_from` fails it can leave the `BTreeMap` in an invalid state, which might be unacceptable.
~This probably needs an FCP since it changes a trait bound, but (as far as I know?) that change cannot break any external code.~
bors [Wed, 29 Jan 2020 13:40:58 +0000 (13:40 +0000)]
Auto merge of #68635 - JohnTitor:rollup-jsc34ac, r=JohnTitor
Rollup of 7 pull requests
Successful merges:
- #67722 (Minor: note how Any is an unsafe trait in SAFETY comments)
- #68586 (Make conflicting_repr_hints a deny-by-default c-future-compat lint)
- #68598 (Fix null synthetic_implementors error)
- #68603 (Changelog: Demonstrate final build-override syntax)
- #68609 (Set lld flavor for MSVC to link.exe)
- #68611 (Correct ICE caused by macros generating invalid spans.)
- #68627 (Document that write_all will not call write if given an empty buffer)
Yuki Okushi [Wed, 29 Jan 2020 09:56:34 +0000 (18:56 +0900)]
Rollup merge of #68627 - joshtriplett:write-all-none, r=Dylan-DPC
Document that write_all will not call write if given an empty buffer
Some types of Write instances have a semantic meaning associated with
writing an empty buffer, such as sending an empty packet. This works
when calling `write` directly, and supplying an empty buffer. However,
calling `write_all` on an empty buffer will simply never call `write`,
because `write_all` assumes it has no work to do.
Document this behavior, to help prospective users of
datagram-packet-style Write instances.
Yuki Okushi [Wed, 29 Jan 2020 09:56:22 +0000 (18:56 +0900)]
Rollup merge of #67722 - petertodd:2019-improve-any-comment, r=Mark-Simulacrum
Minor: note how Any is an unsafe trait in SAFETY comments
Motivation: helpful to people like myself reading the standard library source to better understand how to use Any, especially if we do go ahead with https://github.com/rust-lang/rust/pull/67562 and make it an unsafe trait.
bors [Wed, 29 Jan 2020 07:44:36 +0000 (07:44 +0000)]
Auto merge of #68572 - tmiasko:sanitizer-use-after-scope, r=nikic
Detect use-after-scope bugs with AddressSanitizer
Enable use-after-scope checks by default when using AddressSanitizer.
They allow to detect incorrect use of stack objects after their scope
have already ended. The detection is based on LLVM lifetime intrinsics.
To facilitate the use of this functionality, the lifetime intrinsics are
now emitted regardless of optimization level if enabled sanitizer makes
use of them.
bors [Wed, 29 Jan 2020 01:28:55 +0000 (01:28 +0000)]
Auto merge of #68625 - JohnTitor:rollup-20pfcru, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #68289 (Don't ICE on path-collision in dep-graph)
- #68378 (Add BTreeMap::remove_entry)
- #68553 (Fix run button positionning in case of scrolling)
- #68556 (rustdoc: Fix re-exporting primitive types)
- #68582 (Add E0727 long explanation)
- #68592 (fix: typo in vec.rs)
- #68619 (Fix a few spelling mistakes)
- #68620 (Update links to WASI docs in time.rs module)
Josh Triplett [Wed, 29 Jan 2020 01:22:38 +0000 (17:22 -0800)]
Document that write_all will not call write if given an empty buffer
Some types of Write instances have a semantic meaning associated with
writing an empty buffer, such as sending an empty packet. This works
when calling `write` directly, and supplying an empty buffer. However,
calling `write_all` on an empty buffer will simply never call `write`,
because `write_all` assumes it has no work to do.
Document this behavior, to help prospective users of
datagram-packet-style Write instances.
Yuki Okushi [Wed, 29 Jan 2020 00:34:54 +0000 (09:34 +0900)]
Rollup merge of #68620 - kubkon:patch-1, r=Dylan-DPC
Update links to WASI docs in time.rs module
Since the docs for the WASI API are now evolving in [WebAssembly/WASI] repo,
I thought it might be useful to update the links in the docs to point to that location
instead of using the outdated `CraneStation/wasmtime` destination.
Yuki Okushi [Wed, 29 Jan 2020 00:34:48 +0000 (09:34 +0900)]
Rollup merge of #68556 - ollie27:rustdoc_primitive_re-export, r=GuillaumeGomez
rustdoc: Fix re-exporting primitive types
* Generate links to the primitive type docs for re-exports.
* Don't ICE on cross crate primitive type re-exports.
* Make primitive type re-exports show up cross crate.
Jakub Konka [Tue, 28 Jan 2020 22:34:00 +0000 (23:34 +0100)]
Update links to WASI docs in time.rs module
Since the docs for the WASI API are now evolving in [WebAssembly/WASI] repo,
I thought it might be useful to update the links in the docs to point to that location
instead of using the outdated `CraneStation/wasmtime` destination.
bors [Tue, 28 Jan 2020 20:26:24 +0000 (20:26 +0000)]
Auto merge of #68606 - jonas-schievink:normalize-fastpath, r=Zoxc
Add an early-exit to `QueryNormalizer::fold_ty`
Pulled out from https://github.com/rust-lang/rust/pull/68524, this results in a ~60-70% reduction in compile time for the await-call-tree benchmarks. This should unblock https://github.com/rust-lang/rust/issues/67982 as well.
bors [Tue, 28 Jan 2020 16:25:35 +0000 (16:25 +0000)]
Auto merge of #68533 - tmiasko:compiletest, r=nikomatsakis
compiletest: Unit tests for `EarlyProps` (+ small cleanup)
* Parse `EarlyProps` from a reader
* Add unit tests for `EarlyProps`
* Remove unused `llvm-cxxflags` option
* Remove unnecessary memory allocations in `iter_header`
* Update mode list displayed in `--help`
bors [Tue, 28 Jan 2020 08:44:20 +0000 (08:44 +0000)]
Auto merge of #68529 - TimDiekmann:rename-alloc, r=Amanieu
Rename `Alloc` to `AllocRef`
The allocator-wg has decided to merge this change upstream in https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-577122958.
This renames `Alloc` to `AllocRef` because types that implement `Alloc` are a reference, smart pointer, or ZSTs. It is not possible to have an allocator like `MyAlloc([u8; N])`, that owns the memory and also implements `Alloc`, since that would mean, that moving a `Vec<T, MyAlloc>` would need to correct the internal pointer, which is not possible as we don't have move constructors.
For further explanation please see https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-489464843 and the comments after that one.
Additionally it clarifies the semantics of `Clone` on an allocator. In the case of `AllocRef`, it is clear that the cloned handle still points to the same allocator instance, and that you can free data allocated from one handle with another handle.
The initial proposal was to rename `Alloc` to `AllocHandle`, but `Ref` expresses the semantics better than `Handle`. Also, the only appearance of `Handle` in `std` are for windows specific resources, which might be confusing.
Blocked on https://github.com/rust-lang/miri/pull/1160
bors [Tue, 28 Jan 2020 05:31:34 +0000 (05:31 +0000)]
Auto merge of #68234 - CAD97:slice-from-raw-parts, r=KodrAus
Stabilize ptr::slice_from_raw_parts[_mut]
Closes #36925, the tracking issue.
Initial impl: #60667
r? @rust-lang/libs
In addition to stabilizing, I've adjusted the example of `ptr::slice_from_raw_parts` to use `slice_from_raw_parts` instead of `slice_from_raw_parts_mut`, which was unnecessary for the example as written.
Yuki Okushi [Tue, 28 Jan 2020 01:48:17 +0000 (10:48 +0900)]
Rollup merge of #68570 - cr1901:msp430-fix-1-2020, r=alexcrichton
Bump LLVM submodule to fix LLVM assertion failure in MSP430 interrupt generation.
This PR brings in changes introduced by [this cherry-pick](https://github.com/rust-lang/llvm-project/pull/37) to the Rust repository.
Nightlies downloaded from `rustup` do not appear to have llvm assertions enabled; the assertion failure [sometimes](https://github.com/YuhanLiin/msp430fr2355-quickstart/issues/3) causes link errors that shouldn't occur. I couldn't find any indication of other bugs; however, it should still be fixed.
These methods are small and self-contained, and are used as the basis for the existing `DebugMap::entry` method, so have been used in the wild for the last 6 months or so.
bors [Mon, 27 Jan 2020 11:59:57 +0000 (11:59 +0000)]
Auto merge of #68566 - pietroalbini:rollup-22hbo3e, r=pietroalbini
Rollup of 4 pull requests
Successful merges:
- #67928 (Update RELEASES.md for 1.41.0)
- #68370 (Ensure that we error when calling "const extern fn" with wrong convention)
- #68531 ([self-profiler] Two small cleanups)
- #68562 (Fix spelling errors)
projects / rust.git / log