Rollup merge of #70138 - RalfJung:throw-not-return, r=oli-obk
do not 'return' in 'throw_' macros
In https://github.com/rust-lang/rust/pull/69839 we turned a closure into a `try` block, but it turns out that does not work with our `throw_` macros, which `return` so they skip the `try`.
Here we fix that. For some reason that means we also have to remove some `;`.
Rollup merge of #70092 - eddyb:hir-items-are-just-nodes, r=Zoxc
hir: replace "items" terminology with "nodes" where appropriate.
The newly added `HirOwnerItems` confused me before I realized that "items" there actually referred to HIR nodes, not `hir:Item` or "item-like" (which we should IMO replace with "owner").
I suspect the naming had something to do with `ItemLocalId`'s use of "item".
That is, `ItemLocalId` could be interpreted to mean one of two things:
* `IntraItemNodeId` i.e. `IntraOwnerNodeId`
* this is IMO correct, and I'd even like to rename it, but I didn't want to throw that into this PR
* `IntraOwnerItemId`
* this is what `HirOwnerItems` would seem to imply
Rollup merge of #70089 - eddyb:closure-sig-infer, r=nikomatsakis
rustc_infer: remove InferCtxt::closure_sig as the FnSig is always shallowly known.
That is, `ClosureSubsts` is always created (in `rustc_typeck::check::closure`) with a `FnSig`, as the number of inputs is known, even if they might all have inference types.
The only useful thing `InferCtxt::closure_sig` was doing is resolving an inference variable used just to get the `ty::FnPtr` containing that `FnSig` into `ClosureSubsts`.
The ideal way to solve this would be to add a constructor for `ClosureSubsts`, that combines the parent `Substs`, the closure kind, the signature, and capture types together, but for now I've went with resolving the inference types just after unifying them with the real types.
Rollup merge of #69965 - mark-i-m:codegen-utils, r=eddyb
Refactorings to get rid of rustc_codegen_utils
r? @eddyb
cc #45276
After this, the only modules left in `rustc_codegen_utils` are
- `link`: a bunch of linking-related functions (many dealing with file names). These are mostly consumed by save analysis, rustc_driver, rustc_interface, and of course codegen. I assume they live here because we don't want a dependency of save analysis on codegen... Perhaps they can be moved to librustc?
- ~`symbol_names` and `symbol_names_test`: honestly it seems odd that `symbol_names_test` is not a submodule of `symbol_names`. It seems like these could honestly live in their own crate or move to librustc. Already name mangling is exported as the `symbol_name` query.~ (move it to its own crate)
I don't mind doing either of the above as part of this PR or a followup if you want.
bors [Sat, 21 Mar 2020 04:34:04 +0000 (04:34 +0000)]
Auto merge of #70205 - Centril:rollup-0jq9k4s, r=Centril
Rollup of 16 pull requests
Successful merges:
- #65097 (Make std::sync::Arc compatible with ThreadSanitizer)
- #69033 (Use generator resume arguments in the async/await lowering)
- #69997 (add `Option::{zip,zip_with}` methods under "option_zip" gate)
- #70038 (Remove the call that makes miri fail)
- #70058 (can_begin_literal_maybe_minus: `true` on `"-"? lit` NTs.)
- #70111 (BTreeMap: remove shared root)
- #70139 (add delay_span_bug to TransmuteSizeDiff, just to be sure)
- #70165 (Remove the erase regions MIR transform)
- #70166 (Derive PartialEq, Eq and Hash for RangeInclusive)
- #70176 (Add tests for #58319 and #65131)
- #70177 (Fix oudated comment for NamedRegionMap)
- #70184 (expand_include: set `.directory` to dir of included file.)
- #70187 (more clippy fixes)
- #70188 (Clean up E0439 explanation)
- #70189 (Abi::is_signed: assert that we are a Scalar)
- #70194 (#[must_use] on split_off())
Rollup merge of #70189 - RalfJung:is_signed, r=eddyb
Abi::is_signed: assert that we are a Scalar
A bit more sanity checking, suggested by @eddyb. This makes this method actually "safer" than `TyS::is_signed`, so I made sure Miri consistently uses the `Abi` version.
Though I am not sure if this would have caught the mistake where the layout of a zero-sized enum was asked for its sign.
Rollup merge of #70166 - CDirkx:range-inclusive-derives, r=cramertj
Derive PartialEq, Eq and Hash for RangeInclusive
The manual implementation of `PartialEq`, `Eq` and `Hash` for `RangeInclusive` was functionally equivalent to a derived implementation.
This change removes the manual implementation and adds the respective derives.
A side effect of this change is that the derives also add implementations for `StructuralPartialEq` and `StructuralEq`, which enables `RangeInclusive` to be used in const generics, closing #70155.
This change is enabled by #68835, which changed the field `is_empty: Option<bool>` to `exhausted: bool` removing the need for *semantic* equality instead of *structural* equality.
These implementations both test for *structural* equality, with the same order of field comparisons, and the bound `Idx: PartialEq` is the same.
## Eq
original [`Eq`](https://github.com/rust-lang/rust/blob/f4c675c476c18b1a11041193f2f59d695b126bc8/src/libcore/ops/range.rs#L361-L362) implementation:
```rust
#[stable(feature = "inclusive_range", since = "1.26.0")]
impl<Idx: Eq> Eq for RangeInclusive<Idx> {}
```
expanded derive implementation (using `cargo expand ops::range`):
```rust
#[stable(feature = "inclusive_range", since = "1.26.0")]
impl<Idx> crate::marker::StructuralEq for RangeInclusive<Idx> {}
#[automatically_derived]
#[allow(unused_qualifications)]
#[stable(feature = "inclusive_range", since = "1.26.0")]
impl<Idx: crate::cmp::Eq> crate::cmp::Eq for RangeInclusive<Idx> {
#[inline]
#[doc(hidden)]
fn assert_receiver_is_total_eq(&self) -> () {
{
let _: crate::cmp::AssertParamIsEq<Idx>;
let _: crate::cmp::AssertParamIsEq<Idx>;
let _: crate::cmp::AssertParamIsEq<bool>;
}
}
}
```
These implementations are equivalent since `Eq` is just a marker trait and the bound `Idx: Eq` is the same.
## Hash
original [`Hash`](https://github.com/rust-lang/rust/blob/f4c675c476c18b1a11041193f2f59d695b126bc8/src/libcore/ops/range.rs#L364-L371) implementation:
```rust
#[stable(feature = "inclusive_range", since = "1.26.0")]
impl<Idx: Hash> Hash for RangeInclusive<Idx> {
fn hash<H: Hasher>(&self, state: &mut H) {
self.start.hash(state);
self.end.hash(state);
self.exhausted.hash(state);
}
}
```
expanded derive implementation (using `cargo expand ops::range`):
```rust
#[automatically_derived]
#[allow(unused_qualifications)]
#[stable(feature = "inclusive_range", since = "1.26.0")]
impl<Idx: crate::hash::Hash> crate::hash::Hash for RangeInclusive<Idx> {
fn hash<__H: crate::hash::Hasher>(&self, state: &mut __H) -> () {
match *self { RangeInclusive { start: ref __self_0_0, end: ref __self_0_1, exhausted: ref __self_0_2 } => {
crate::hash::Hash::hash(&(*__self_0_0), state);
crate::hash::Hash::hash(&(*__self_0_1), state);
crate::hash::Hash::hash(&(*__self_0_2), state)
}
}
}
}
```
These implementations are functionally equivalent, with the same order of field hashing, and the bound `Idx: Hash` is the same.
Rollup merge of #70111 - Mark-Simulacrum:btree-no-shared, r=cuviper
BTreeMap: remove shared root
This replaces the shared root with `Option`s in the BTreeMap code, and then slightly cleans up the node manipulation code taking advantage of the removal of the shared root. I expect that further simplification is possible, but wanted to get this posted for initial review.
Note that `BTreeMap::new()` continues to not allocate.
Benchmarks seem within the margin of error/unaffected, as expected for an entirely predictable branch.
```
name alloc-bench-a ns/iter alloc-bench-b ns/iter diff ns/iter diff % speedup
btree::map::iter_mut_20 20 21 1 5.00% x 0.95
btree::set::clone_100 1,360 1,439 79 5.81% x 0.95
btree::set::clone_100_and_into_iter 1,319 1,434 115 8.72% x 0.92
btree::set::clone_10k 143,515 150,991 7,476 5.21% x 0.95
btree::set::clone_10k_and_clear 142,792 152,916 10,124 7.09% x 0.93
btree::set::clone_10k_and_into_iter 146,019 154,561 8,542 5.85% x 0.94
```
Rollup merge of #70058 - Centril:fix-70050, r=petrochenkov
can_begin_literal_maybe_minus: `true` on `"-"? lit` NTs.
Make `can_begin_literal_or_bool` (renamed to `can_begin_literal_maybe_minus`) accept `NtLiteral(e) | NtExpr(e)` where `e` is either a literal or a negated literal.
Recently in a russian rust begginers telegram chat a newbie asked (translated):
> Are there any methods for these conversions:
>
> 1. `(Option<A>, Option<B>) -> Option<(A, B)>`
> 2. `Vec<Option<T>> -> Option<Vec<T>>`
>
> ?
While second (2.) is clearly `vec.into_iter().collect::<Option<Vec<_>>()`, the
first one isn't that clear.
I couldn't find anything similar in the `core` and I've come to this solution:
```rust
let tuple: (Option<A>, Option<B>) = ...;
let res: Option<(A, B)> = tuple.0.and_then(|a| tuple.1.map(|b| (a, b)));
```
However this solution isn't "nice" (same for just `match`/`if let`), so I thought
that this functionality should be in `core`.
I'm not confident the HIR lowering is completely correct, there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.
Make std::sync::Arc compatible with ThreadSanitizer
The memory fences used previously in Arc implementation are not properly
understood by thread sanitizer as synchronization primitives. This had
unfortunate effect where running any non-trivial program compiled with
`-Z sanitizer=thread` would result in numerous false positives.
Replace acquire fences with acquire loads to address the issue.
bors [Fri, 20 Mar 2020 19:02:32 +0000 (19:02 +0000)]
Auto merge of #69509 - RalfJung:debug-assert-write, r=eddyb
debug-assert ptr sanity in ptr::write
This is a re-submission of the parts that we removed from https://github.com/rust-lang/rust/pull/69208 due to ["interesting" test failures](https://github.com/rust-lang/rust/pull/69208#issuecomment-591310437).
Mark Rousskov [Wed, 18 Mar 2020 23:00:15 +0000 (19:00 -0400)]
Simplify ensure_root_is_owned callers
This makes ensure_root_is_owned return a reference to the (now guaranteed to
exist) root, allowing callers to operate on it without going through another
unwrap.
Unfortunately this is only rarely useful as it's frequently the case that both
the length and the root need to be accessed and field-level borrows in methods
don't yet exist.
Yuki Okushi [Fri, 20 Mar 2020 08:02:05 +0000 (17:02 +0900)]
Rollup merge of #69935 - davidtwco:issue-69925, r=eddyb
codegen/mir: support polymorphic `InstanceDef`s
cc #69925
This PR modifies the use of `subst_and_normalize_erasing_regions` on parts of the MIR bodies returned from `instance_mir`, so that `InstanceDef::CloneShim` and `InstanceDef::DropGlue` (where there is a type) do not perform substitutions. This avoids double substitutions and enables polymorphic `InstanceDef`s.
Yuki Okushi [Fri, 20 Mar 2020 08:02:01 +0000 (17:02 +0900)]
Rollup merge of #69618 - hniksic:mem-forget-doc-fix, r=RalfJung
Clarify the relationship between `forget()` and `ManuallyDrop`.
As discussed on reddit, this commit addresses two issues with the
documentation of `mem::forget()`:
* The documentation of `mem::forget()` can confuse the reader because of the
discrepancy between usage examples that show correct usage and the
accompanying text which speaks of the possibility of double-free. The
text that says "if the panic occurs before `mem::forget` was called"
refers to a variant of the second example that was never shown, modified
to use `mem::forget` instead of `ManuallyDrop`. Ideally the documentation
should show both variants, so it's clear what it's talking about.
Also, the double free could be fixed just by placing `mem::forget(v)`
before the construction of `s`. Since the lifetimes of `s` and `v`
wouldn't overlap, there would be no point where panic could cause a double
free. This could be mentioned, and contrasted against the more robust fix
of using `ManuallyDrop`.
* This sentence seems unjustified: "For some types, operations such as
passing ownership (to a funcion like `mem::forget`) requires them to
actually be fully owned right now [...]". Unlike C++, Rust has no move
constructors, its moves are (possibly elided) bitwise copies. Even if you
pass an invalid object to `mem::forget`, no harm should come to pass
because `mem::forget` consumes the object and exists solely to prevent
drop, so there no one left to observe the invalid state state.
Tomasz Miąsko [Fri, 20 Mar 2020 00:00:00 +0000 (00:00 +0000)]
Make std::sync::Arc compatible with ThreadSanitizer
The memory fences used previously in Arc implementation are not properly
understood by ThreadSanitizer as synchronization primitives. This had
unfortunate effect where running any non-trivial program compiled with
`-Z sanitizer=thread` would result in numerous false positives.
Replace acquire fences with acquire loads when using ThreadSanitizer to
address the issue.
CDirkx [Thu, 19 Mar 2020 19:45:47 +0000 (20:45 +0100)]
Derive PartialEq, Eq and Hash for RangeInclusive
The manual implementation of PartialEq, Eq and Hash for RangeInclusive was functionally equivalent to a derived implementation.
This change removes the manual implementation and adds the respective derives.
A side effect of this change is that the derives also add implementations for StructuralPartialEq and StructuralEq, which enables RangeInclusive to be used in const generics.
bors [Thu, 19 Mar 2020 16:07:59 +0000 (16:07 +0000)]
Auto merge of #69402 - GuillaumeGomez:extend-search, r=kinnison
Extend search
I realized that when looking for "struct:String" in the rustdoc search for example, the "in arguments" and "returned" tabs were always empty. After some investigation, I realized it was because we only provided the name, and not the type, making it impossible to pass the "type filtering" check.
To resolve this, I added the type alongside the name. Note for the future: we could improve this by instead only registering the path id and use the path dictionary directly. The only problem with that solution (which I already tested) is that it becomes complicated for types in other crates. It'd force us to handle both case with an id and a case with `(name, type)`. I found the current PR big enough to not want to provide it directly. However, I think this is definitely worth it to make it work this way in the future.
About the two tests I added: they don't have much interest except checking that we actually have something returned in the search in the cases of a type filtering with and without literal search.
I also had to update a bit the test script to add the new locally global (haha) variable I created (`NO_TYPE_FILTER`). I added this variable to make the code easier to read than just "-1".
Hrvoje Niksic [Wed, 4 Mar 2020 21:12:53 +0000 (22:12 +0100)]
Restore (and reword) the warning against passing invalid values to mem::forget.
As pointed out by Ralf Jung, dangling references and boxes are
undefined behavior as per
https://doc.rust-lang.org/reference/behavior-considered-undefined.html
and the Miri checker.
Hrvoje Niksic [Sun, 1 Mar 2020 20:31:08 +0000 (21:31 +0100)]
Clarify the relationship between `forget()` and `ManuallyDrop`.
As discussed on reddit, this commit addresses two issues with the
documentation of `mem::forget()`:
* The documentation of `mem::forget()` can confuse the reader because of the
discrepancy between usage examples that show correct usage and the
accompanying text which speaks of the possibility of double-free. The
text that says "if the panic occurs before `mem::forget` was called"
refers to a variant of the second example that was never shown, modified
to use `mem::forget` instead of `ManuallyDrop`. Ideally the documentation
should show both variants, so it's clear what it's talking about.
Also, the double free could be fixed just by placing `mem::forget(v)`
before the construction of `s`. Since the lifetimes of `s` and `v`
wouldn't overlap, there would be no point where panic could cause a double
free. This could be mentioned, and contrasted against the more robust fix
of using `ManuallyDrop`.
* This sentence seems unjustified: "For some types, operations such as
passing ownership (to a funcion like `mem::forget`) requires them to
actually be fully owned right now [...]". Unlike C++, Rust has no move
constructors, its moves are (possibly elided) bitwise copies. Even if you
pass an invalid object to `mem::forget`, no harm should come to pass
because `mem::forget` consumes the object and exists solely to prevent
drop, so there no one left to observe the invalid state state.
bors [Thu, 19 Mar 2020 09:18:49 +0000 (09:18 +0000)]
Auto merge of #66131 - eddyb:local-def-id, r=petrochenkov
rustc: use LocalDefId instead of DefIndex where possible.
That is, wherever `DefIndex` always referred to a "def" in the local crate, I replaced it with `LocalDefId`.
While `LocalDefId` already existed, it wasn't used a lot, but I hope I'm on the right track.
Unresolved questions:
* [x] ~~should `LocalDefId` implement `rustc_index::Idx`?~~
* ~~this would get rid of a couple more `DefIndex` uses~~
* [x] ~~should `LocalDefId` be encoded/decoded as just a `DefIndex`?~~
* ~~right now it's a bit messy, `LocalDefId` encodes/decodes like `DefId`~~
* [x] ~~should `DefId::assert_local` be named something else, like `expect_local`?~~
A future PR should change `tcx.hir().local_def_id(...)` to return `LocalDefId` instead of `DefId`, as changing it in this PR would be too noisy.
r? @michaelwoerister cc @nikomatsakis @petrochenkov @Zoxc
bors [Thu, 19 Mar 2020 05:57:57 +0000 (05:57 +0000)]
Auto merge of #70132 - Centril:rollup-oe8unsn, r=Centril
Rollup of 9 pull requests
Successful merges:
- #68941 (Properly handle Spans that reference imported SourceFiles)
- #69036 (rustc: don't resolve Instances which would produce malformed shims.)
- #69443 (tidy: Better license checks.)
- #69814 (Smaller and more correct generator codegen)
- #69929 (Regenerate tables for Unicode 13.0.0)
- #69959 (std: Don't abort process when printing panics in tests)
- #69969 (unix: Set a guard page at the end of signal stacks)
- #70005 ([rustdoc] Improve visibility for code blocks warnings)
- #70088 (Use copy bound in atomic operations to generate simpler MIR)
Rollup merge of #70005 - GuillaumeGomez:code-block-signs, r=kinnison
[rustdoc] Improve visibility for code blocks warnings
It appeared that a lot of people didn't notice when a code block was meant to fail compilation or wasn't tested at all. The changes here make the colors less transparent and the icon bigger. So before it looked like this:
Rollup merge of #69969 - iximeow:sigstack-guard-page, r=cuviper
unix: Set a guard page at the end of signal stacks
This mitigates possible issues when signal stacks overflow, which could
manifest as segfaults or in unlucky circumstances possible clobbering of
other memory values as stack overflows tend to enable.
I went ahead and made a PR for this because it's a pretty small change, though if I should open an issue/RFC for this and discuss there first I'll happily do so. I've also added some example programs that demonstrate the uncomfortably clobber-happy behavior we currently have, and the segfaults that could/should result instead, [here](https://github.com/iximeow/jubilant-train).
Rollup merge of #69959 - alexcrichton:fix-panic-in-print, r=Mark-Simulacrum
std: Don't abort process when printing panics in tests
This commit fixes an issue when using `set_print` and friends, notably
used by libtest, to avoid aborting the process if printing panics. This
previously panicked due to borrowing a mutable `RefCell` twice, and this
is worked around by borrowing these cells for less time, instead
taking out and removing contents temporarily.
It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it, ultimately reaching a `Resume` terminator, which we already handled correctly. Future MIR optimizations might optimize that out, though.
Rollup merge of #69443 - ehuss:tidy-license, r=skade,Mark-Simulacrum
tidy: Better license checks.
This implements some improvements to the license checks in tidy:
* Use `cargo_metadata` instead of parsing vendored crates. This allows license checks to run without vendoring enabled, and allows the checks to run on PR builds.
* Check for stale entries.
* Check that the licenses for exceptions are what we think they are.
* Verify exceptions do not leak into the runtime.
Closes #62618
Closes #62619
Closes #63238 (I think)
There are some substantive changes here. The follow licenses have changed from the original comments:
* openssl BSD+advertising clause to Apache-2.0
* pest MPL2 to MIT/Apache-2.0
* smallvec MPL2 to MIT/Apache-2.0
* clippy lints MPL2 to MIT OR Apache-2.0