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)
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.
bors [Mon, 27 Jan 2020 03:01:59 +0000 (03:01 +0000)]
Auto merge of #68447 - estebank:sugg-type-param, r=petrochenkov
Suggest defining type parameter when appropriate
```
error[E0412]: cannot find type `T` in this scope
--> file.rs:3:12
|
3 | impl Trait<T> for Struct {}
| - ^ not found in this scope
| |
| help: you might be missing a type parameter: `<T>`
```
A `struct` with only a single non-ZST field (let's call it `foo`) can be marked as `#[repr(transparent)]`. Such a `struct` has the same layout and ABI as `foo`. Here, we also extend this ability to `enum`s with only one variant, subject to the same restrictions as for the equivalent `struct`. That is, you can now write:
which, in terms of layout and ABI, is equivalent to:
```rust
#[repr(transparent)]
struct Foo(u8);
```
## Motivation
This is not a major feature that will unlock new and important use-cases. The utility of `repr(transparent)` `enum`s is indeed limited. However, there is still some value in it:
1. It provides conceptual simplification of the language in terms of treating univariant `enum`s and `struct`s the same, as both are product types. Indeed, languages like Haskell only have `data` as the only way to construct user-defined ADTs in the language.
2. In rare occasions, it might be that the user started out with a univariant `enum` for whatever reason (e.g. they thought they might extend it later). Now they want to make this `enum` `transparent` without breaking users by turning it into a `struct`. By lifting the restriction here, now they can.
## Technical specification
The reference specifies [`repr(transparent)` on a `struct`](https://doc.rust-lang.org/nightly/reference/type-layout.html#the-transparent-representation) as:
> ### The transparent Representation
>
> The `transparent` representation can only be used on `struct`s that have:
> - a single field with non-zero size, and
> - any number of fields with size 0 and alignment 1 (e.g. `PhantomData<T>`).
>
> Structs with this representation have the same layout and ABI as the single non-zero sized field.
>
> This is different than the `C` representation because a struct with the `C` representation will always have the ABI of a `C` `struct` while, for example, a struct with the `transparent` representation with a primitive field will have the ABI of the primitive field.
>
> Because this representation delegates type layout to another type, it cannot be used with any other representation.
Here, we amend this to include univariant `enum`s as well with the same static restrictions and the same effects on dynamic semantics.
## Tests
All the relevant tests are adjusted in the PR diff but are recounted here:
- `src/test/ui/repr/repr-transparent.rs` checks that `repr(transparent)` on an `enum` must be univariant, rather than having zero or more than one variant. Restrictions on the fields inside the only variants, like for those on `struct`s, are also checked here.
- A number of codegen tests are provided as well:
- `src/test/codegen/repr-transparent.rs` (the canonical test)
- `src/test/codegen/repr-transparent-aggregates-1.rs`
- `src/test/codegen/repr-transparent-aggregates-2.rs`
- `src/test/codegen/repr-transparent-aggregates-3.rs`
- `src/test/ui/lint/lint-ctypes-enum.rs` tests the interactions with the `improper_ctypes` lint.
## History
- 2019-04-30, RFC https://github.com/rust-lang/rfcs/pull/2645
Author: @mjbshaw
Reviewers: The Language Team
This is the RFC that proposes allowing `#[repr(transparent)]` on `enum`s and `union`.
- 2019-06-11, PR https://github.com/rust-lang/rust/pull/60463
Author: @mjbshaw
Reviewers: @varkor and @rkruppe
The PR reorganizes the static checks taking advantage of the fact that `struct`s and `union`s are internally represented as ADTs with a single variant.
- This PR stabilizes `transparent_enums`.
## Related / possible future work
The remaining work here is to figure out the semantics of `#[repr(transparent)]` on `union`s and stabilize those. This work continues to be tracked in https://github.com/rust-lang/rust/issues/60405.
Tomasz Miąsko [Mon, 27 Jan 2020 00:00:00 +0000 (00:00 +0000)]
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.
Oliver Middleton [Sun, 26 Jan 2020 21:28:09 +0000 (21:28 +0000)]
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.
bors [Sun, 26 Jan 2020 21:01:13 +0000 (21:01 +0000)]
Auto merge of #68407 - eddyb:iter-macro-backtrace, r=petrochenkov
rustc_span: return an impl Iterator instead of a Vec from macro_backtrace.
Having `Span::macro_backtrace` produce an `impl Iterator<Item = ExpnData>` allows #67359 to use it instead of rolling its own similar functionality.
The move from `MacroBacktrace` to `ExpnData` (which the first two commits are prerequisites for) both eliminates unnecessary allocations, and is strictly more flexible (exposes more information).
Esteban Küber [Wed, 22 Jan 2020 07:01:21 +0000 (23:01 -0800)]
Suggest defining type parameter when appropriate
```
error[E0412]: cannot find type `T` in this scope
--> file.rs:3:12
|
3 | impl Trait<T> for Struct {}
| - ^ not found in this scope
| |
| help: you might be missing a type parameter: `<T>`
```
projects / rust.git / log