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`
Andrew Paverd [Mon, 13 Jan 2020 13:25:39 +0000 (13:25 +0000)]
Add support for Control Flow Guard on Windows.
This patch enables rustc to emit the required LLVM module flags to enable Control Flow Guard metadata (cfguard=1) or metadata and checks (cfguard=2). The LLVM module flags are ignored on unsupported targets and operating systems.
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)
bors [Mon, 27 Jan 2020 08:42:56 +0000 (08:42 +0000)]
Auto merge of #68165 - thomcc:lt_ones, r=sfackler
Add leading_ones and trailing_ones methods to the primitive integer types
I was surprised these were missing (given that `leading_zeros` and `trailing_zeros` exist), and they seem trivial and hopefully not controversial.
Note that there's some precedent in that `count_ones` and `count_zeros` are both supported even though only one of these has an intrinsic.
I'm not sure if these need a `rustc_const_unstable` flag (the tests don't seem to mind that it's missing). I just made them const, since there's not really any reason for these to be non-const when the `_zeros` variants are const.
Note: My understanding is trivial stuff like (hopefully) this can land without an RFC, but I'm not fully sure about the process though. Questions like "when does the tracking issue get filed?", are a total mystery to me. So, any guidance is appreciated, and sorry in advance if I should have gone through some more involved process for this.