Yuki Okushi [Sat, 8 Aug 2020 21:41:22 +0000 (06:41 +0900)]
Rollup merge of #75248 - TimDiekmann:NonNull-as_mut_ptr, r=RalfJung
Add `as_mut_ptr` to `NonNull<[T]>`
Adds `as_mut_ptr` to shortcut converting a `NonNull<[T]>` to `*mut T` as proposed in https://github.com/rust-lang/rust/issues/74265#issuecomment-669702969.
Yuki Okushi [Sat, 8 Aug 2020 21:41:20 +0000 (06:41 +0900)]
Rollup merge of #75162 - poliorcetics:move-documentation-fix, r=jyn514
Fix the documentation for move about Fn traits implementations
Fixes #74997.
This uses the note from the [reference](https://doc.rust-lang.org/reference/types/closure.html#call-traits-and-coercions) but I can also just put a link to it or do both.
bors [Sat, 8 Aug 2020 18:15:50 +0000 (18:15 +0000)]
Auto merge of #75163 - canova:map_into_keys_values, r=dtolnay
Implement `into_keys` and `into_values` for associative maps
This PR implements `into_keys` and `into_values` for HashMap and BTreeMap types. They are implemented as unstable, under `map_into_keys_values` feature.
Fixes #55214.
r? @dtolnay
bors [Sat, 8 Aug 2020 15:57:12 +0000 (15:57 +0000)]
Auto merge of #75260 - davidtwco:polymorphization-promoted-substs, r=lcnr
polymorphize: unevaluated constants
This PR makes polymorphization visit the promoted MIR of unevaluated constants with available promoted MIR instead of visiting the substitutions of that constant - which will mark all of the generic parameters as used; in addition polymorphization will now visit non-promoted unevaluated constants rather than visit their substs.
bors [Sat, 8 Aug 2020 13:33:53 +0000 (13:33 +0000)]
Auto merge of #74533 - nikic:issue-74425, r=eddyb
Emit == null instead of <= null for niche check
When the niche maximum is zero, emit a "== zero" check instead of a "<= zero" check. In particular, this avoids the awkward case of "<= null". While LLVM does canonicalize this to "== null", this apparently doesn't happen for constant expressions, leading to the issue in #74425. While that can be addressed on the LLVM side, it still seems prudent to emit sensible IR here, because this will allow null checks to be optimized earlier in the pipeline.
bors [Sat, 8 Aug 2020 09:46:16 +0000 (09:46 +0000)]
Auto merge of #75282 - RalfJung:miri-black-box, r=oli-obk
do not call black_box on Miri
Helps with https://github.com/rust-lang/rust/issues/75274 (but https://github.com/rust-lang/rust/pull/74932 introduced unrelated breakage that will need a separate fix)
Cc @eggyal r? @Mark-Simulacrum
When the niche maximum is zero, emit a "== zero" check instead of
a "<= zero" check. In particular, this avoid the awkward case of
"<= null". While LLVM does canonicalize this to "!= null", this
appently doesn't happen for constant expressions, leading to the
issue in #74425. While that can be addressed on the LLVM side, it
still seems prudent to emit sensible IR here, because this will
allow null checks to be optimized earlier in the pipeline.
bors [Sat, 8 Aug 2020 03:54:33 +0000 (03:54 +0000)]
Auto merge of #75276 - JohnTitor:rollup-rz4hs0w, r=JohnTitor
Rollup of 7 pull requests
Successful merges:
- #75224 (Don't call a function in function-arguments-naked.rs)
- #75237 (Display elided lifetime for non-reference type in doc)
- #75250 (make MaybeUninit::as_(mut_)ptr const)
- #75253 (clean up const-hacks in int endianess conversion functions)
- #75259 (Add missing backtick)
- #75267 (Small cleanup)
- #75270 (fix a couple of clippy findings)
Yuki Okushi [Sat, 8 Aug 2020 02:36:03 +0000 (11:36 +0900)]
Rollup merge of #75237 - nbdd0121:rustdoc, r=jyn514
Display elided lifetime for non-reference type in doc
In edition 2018 we encourage writing `<'_>` explicitly, so rustdoc should display like such as well.
Fixes #75225
~~Somehow when I run the compiled rustdoc using `cargo +stage2 doc` on other crates, it correctly produces `<'_>`, but I couldn't get the std doc to do the same with `./x.py doc --stage 2`. Might this be related to the recent change to x.py about how the doc is built?~~
Yuki Okushi [Sat, 8 Aug 2020 02:36:02 +0000 (11:36 +0900)]
Rollup merge of #75224 - Aaron1011:fix/function-arguments-naked, r=Amanieu
Don't call a function in function-arguments-naked.rs
Fixes #75096
It's U.B. to use anything other than inline assmebling in a naked
function. Fortunately, the `#break` directive works fine without
anything in the function body.
Eliminate the `SessionGlobals` from `librustc_ast`.
By moving `{known,used}_attrs` from `SessionGlobals` to `Session`. This
means they are accessed via the `Session`, rather than via TLS. A few
`Attr` methods and `librustc_ast` functions are now methods of
`Session`.
All of this required passing a `Session` to lots of functions that didn't
already have one. Some of these functions also had arguments removed, because
those arguments could be accessed directly via the `Session` argument.
`contains_feature_attr()` was dead, and is removed.
Some functions were moved from `librustc_ast` elsewhere because they now need
to access `Session`, which isn't available in that crate.
- `entry_point_type()` --> `librustc_builtin_macros`
- `global_allocator_spans()` --> `librustc_metadata`
- `is_proc_macro_attr()` --> `Session`
bors [Sat, 8 Aug 2020 01:48:35 +0000 (01:48 +0000)]
Auto merge of #74877 - lcnr:min_const_generics, r=oli-obk
Implement the `min_const_generics` feature gate
Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332.
Adds the new feature gate `#![feature(min_const_generics)]`.
This feature gate adds the following limitations to using const generics:
- generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`)
- generic parameters must be either integers, `bool` or `char`.
We do allow arbitrary expressions in associated consts though, meaning that the following is allowed,
even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable.
```rust
trait Foo {
const ASSOC: usize;
}
bors [Sat, 8 Aug 2020 00:00:52 +0000 (00:00 +0000)]
Auto merge of #75048 - eggyal:force-no-tco-start-backtrace-frame, r=Mark-Simulacrum
Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away
I've stumbled across some situations where there (unexpectedly) was no `__rust_begin_short_backtrace` frame on the stack during unwinding.
On closer examination, it appeared that the calls to that function had been tail-call optimised away.
This PR follows [@bjorn3's suggestion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Disabling.20tail.20call.20optimisation.3F/near/205699133), by adding calls to `black_box` that hint to rustc not to perform TCO.
bors [Fri, 7 Aug 2020 17:57:30 +0000 (17:57 +0000)]
Auto merge of #75255 - davidtwco:polymorphisation-symbol-mangling-v0-upvar-closures, r=lcnr
instance: polymorphize upvar closures/generators
This PR modifies how instances are polymorphized so that closures and generators have any closures or generators captured within their upvars also polymorphized.
With the new symbol mangling, a fully polymorphised closure will produce the same symbol regardless of what it was instantiated with. However, when that polymorphised closure captures another closure as an upvar, then the type of that other closure in the upvar substitution wouldn't have been polymorphised. The other closure will still refer to the initial substitutions. Therefore, the polymorphised closure will end up hashing differently but producing the same symbol - triggering `assert_symbols_are_distinct` in MIR partitioning. The old mangling scheme had a hash at the end that meant this didn't happen (this would still have been an issue, we just didn't have a way to notice).
See [this Zulip discussion for further elaboration](https://rust-lang.zulipchat.com/#narrow/stream/216091-t-compiler.2Fwg-polymorphization/topic/symbol.20mangling.20v0.20.E2.9C.95.20polymorphisation/near/206152008).
David Wood [Fri, 7 Aug 2020 16:50:45 +0000 (17:50 +0100)]
ty: add `MAY_POLYMORPHIZE` flag
This commit adds a `MAY_POLYMORPHIZE` which checks for closures and
generators so that polymorphization of substs does not need to traverse
every substs.
David Wood [Fri, 7 Aug 2020 16:11:16 +0000 (17:11 +0100)]
instance: always polymorphize substs
By always polymorphizing substitutions, functions which take closures as
arguments (e.g. `impl Fn()`) can have fewer mono items when some of the
argument closures can be polymorphized.
David Wood [Fri, 7 Aug 2020 11:28:52 +0000 (12:28 +0100)]
instance: polymorphize upvar closures/generators
This commit modifies how instances are polymorphized so that closures
and generators have any closures or generators captured within their
upvars also polymorphized - this avoids symbol clashes with the new
symbol mangling scheme.
David Wood [Fri, 7 Aug 2020 14:59:29 +0000 (15:59 +0100)]
polymorphize: visit promoted MIR
This commit makes polymorphization visited the MIR of unevaluated
constants with available promoted MIR instead of visiting the
substitutions of that constant - which will mark all of the generic
parameters as used.
bors [Fri, 7 Aug 2020 13:29:25 +0000 (13:29 +0000)]
Auto merge of #74627 - petrochenkov:docbeauty2, r=Aaron1011
rustc_ast: Stop using "string typing" for doc comment tokens
Explicitly store their kind and style retrieved during lexing in the `token::DocComment`.
Also don't "beautify" doc comments before converting them to `#[doc]` attributes when passing them to macros (both declarative and procedural).
The trimming of empty lines, lines containing only `*`s, etc is purely a rustdoc's job as a part of its presentation of doc strings to users, rustc must not do this and must pass tokens as precisely as possible internally.
bors [Fri, 7 Aug 2020 08:36:15 +0000 (08:36 +0000)]
Auto merge of #70052 - Amanieu:hashbrown7, r=Mark-Simulacrum
Update hashbrown to 0.8.1
This update includes:
- https://github.com/rust-lang/hashbrown/pull/146, which improves the performance of `Clone` and implements `clone_from`.
- https://github.com/rust-lang/hashbrown/pull/159, which reduces the size of `HashMap` by 8 bytes.
- https://github.com/rust-lang/hashbrown/pull/162, which avoids creating small 1-element tables.
bors [Fri, 7 Aug 2020 06:40:53 +0000 (06:40 +0000)]
Auto merge of #75244 - Manishearth:rollup-dzfyjva, r=Manishearth
Rollup of 4 pull requests
Successful merges:
- #74774 (adds [*mut|*const] ptr::set_ptr_value)
- #75079 (Disallow linking to items with a mismatched disambiguator)
- #75203 (Make `IntoIterator` lifetime bounds of `&BTreeMap` match with `&HashMap` )
- #75227 (Fix ICE when using asm! on an unsupported architecture)
Rollup merge of #75203 - canova:btreemap-into-iter, r=dtolnay
Make `IntoIterator` lifetime bounds of `&BTreeMap` match with `&HashMap`
This is a pretty small change on the lifetime bounds of `IntoIterator` implementations of both `&BTreeMap` and `&mut BTreeMap`. This is loosening the lifetime bounds, so more code should be accepted with this PR. This is lifetime bounds will still be implicit since we have `type Item = (&'a K, &'a V);` in the implementation. This change will make the HashMap and BTreeMap share the same signature, so we can share the same function/trait with both HashMap and BTreeMap in the code.
Fixes #74034.
r? @dtolnay hey, I was touching this file on my previous PR and wanted to fix this on the way. Would you mind taking a look at this, or redirecting it if you are busy?
Rollup merge of #74774 - oliver-giersch:set_data_ptr, r=dtolnay
adds [*mut|*const] ptr::set_ptr_value
I propose the addition of these two functions to `*mut T` and `*const T`, respectively. The motivation for this is primarily byte-wise pointer arithmetic on (potentially) fat pointers, i.e. for types with a `T: ?Sized` bound. A concrete use-case has been discussed in [this](https://internals.rust-lang.org/t/byte-wise-fat-pointer-arithmetic/12739) thread.
TL;DR: Currently, byte-wise pointer arithmetic with potentially fat pointers in not possible in either stable or nightly Rust without making assumptions about the layout of fat pointers, which is currently still an implementation detail and not formally stabilized. This PR adds one function to `*mut T` and `*const T` each, allowing to circumvent this restriction without exposing any internal implementation details.
One possible alternative would be to add specific byte-wise pointer arithmetic functions to the two pointer types in addition to the already existing count-wise functions. However, I feel this fairly niche use case does not warrant adding a whole set of new functions like `add_bytes`, `offset_bytes`, `wrapping_offset_bytes`, etc. (times two, one for each pointer type) to `libcore`.