bors [Tue, 20 Oct 2020 21:27:47 +0000 (21:27 +0000)]
Auto merge of #78162 - GuillaumeGomez:rollup-6a4qiqu, r=GuillaumeGomez
Rollup of 9 pull requests
Successful merges:
- #78046 (Add codegen test for issue #73827)
- #78061 (Optimize const value interning for ZST types)
- #78070 (we can test std and core panic macros together)
- #78076 (Move orphan module-name/mod.rs files into module-name.rs files)
- #78129 (Wrapping intrinsics doc links update.)
- #78133 (Add some MIR-related regression tests)
- #78144 (Don't update `entries` in `TypedArena` if T does not need drop)
- #78145 (Drop unneeded `mut`)
- #78157 (Remove unused type from librustdoc)
Guillaume Gomez [Tue, 20 Oct 2020 19:46:42 +0000 (21:46 +0200)]
Rollup merge of #78145 - LingMan:ast_pretty_mut, r=jonas-schievink
Drop unneeded `mut`
These parameters don't get modified.
Note that `trailing_comment` is pub and gets exported from `rustc_ast_pretty`. Is that considered to be a stable API? If yes, and you want to reserve the right to modify `self` in `trailing_comment` in the future, that hunk would need to be dropped.
Guillaume Gomez [Tue, 20 Oct 2020 19:46:40 +0000 (21:46 +0200)]
Rollup merge of #78144 - bugadani:elements-nodrop, r=oli-obk
Don't update `entries` in `TypedArena` if T does not need drop
As far as I can tell, `entries` is only used when dropping `TypedArenaChunk`s and their contents. It is already ignored there, if T is not `mem::needs_drop`, this PR just skips updating it's value.
You can see `TypedArenaChunk` ignoring the entry count in L71. The reasoning is similar to what you can find in `DroplessArena`.
bors [Tue, 20 Oct 2020 16:59:23 +0000 (16:59 +0000)]
Auto merge of #78151 - tmiasko:disable-match-branch-simplification, r=wesleywiser
Disable MatchBranchSimplification
This optimization can result in unsoundness, because it introduces
additional uses of a place holding the discriminant value without
ensuring that it is valid to do so.
bors [Tue, 20 Oct 2020 08:59:12 +0000 (08:59 +0000)]
Auto merge of #76893 - lcnr:existential-proj, r=estebank
Improve `skip_binder` usage during FlagComputation
It looks like there was previously a bug around `ExistentialPredicate::Projection` here, don't know how to best trigger that one to add a regression test though.
bors [Tue, 20 Oct 2020 03:13:30 +0000 (03:13 +0000)]
Auto merge of #78127 - JohnTitor:rollup-p1bxtqq, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #77612 (BTreeMap: test invariants more thoroughly and more readably)
- #77761 (Assert that pthread mutex initialization succeeded)
- #77778 ([x.py setup] Allow setting up git hooks from other worktrees)
- #77838 (const keyword: brief paragraph on 'const fn')
- #77923 ([net] apply clippy lints)
- #77931 (Fix false positive for `unused_parens` lint)
- #77959 (Tweak ui-tests structure)
- #78105 (change name in .mailmap)
- #78111 (Trait predicate ambiguities are not always in `Self`)
- #78121 (Do not ICE on pattern that uses a binding multiple times in generator)
Yuki Okushi [Tue, 20 Oct 2020 03:11:11 +0000 (12:11 +0900)]
Rollup merge of #78111 - SNCPlay42:not-always-self, r=lcnr
Trait predicate ambiguities are not always in `Self`
When reporting ambiguities in trait predicates, the compiler incorrectly assumed the ambiguity was always in the type the trait should be implemented on, and never the generic parameters of the trait. This caused silly suggestions for predicates like `<KnownType as Trait<_>>`, such as giving explicit types to completely unrelated variables that happened to be of type `KnownType`.
This also reverts #73027, which worked around this issue in some cases and does not appear to be necessary any more.
Yuki Okushi [Tue, 20 Oct 2020 03:11:08 +0000 (12:11 +0900)]
Rollup merge of #77959 - JohnTitor:tweak-test-structure, r=petrochenkov
Tweak ui-tests structure
We have some similar name dirs in ui tests, e.g. `associated-type` and `associated-types` and it can be an issue when we add a test, "which is the right place?". At a glance, it seems they can be merged into one directory so let's merge them to avoid some confusion :)
Yuki Okushi [Tue, 20 Oct 2020 03:11:02 +0000 (12:11 +0900)]
Rollup merge of #77838 - RalfJung:const-fn, r=kennytm
const keyword: brief paragraph on 'const fn'
`const fn` were mentioned in the title, but called "deterministic functions" which is not their main property (though at least currently it is a consequence of being const-evaluable). This adds a brief paragraph discussing them, also in the hopes of clarifying that they do *not* have any effect on run-time uses.
Yuki Okushi [Tue, 20 Oct 2020 03:10:58 +0000 (12:10 +0900)]
Rollup merge of #77761 - tmiasko:pthread-mutex, r=cuviper
Assert that pthread mutex initialization succeeded
If pthread mutex initialization fails, the failure will go unnoticed unless
debug assertions are enabled. Any subsequent use of mutex will also silently
fail, since return values from lock & unlock operations are similarly checked
only through debug assertions.
In some implementations the mutex initialization requires a memory
allocation and so it does fail in practice.
Assert that initialization succeeds to ensure that mutex guarantees
mutual exclusion.
Tomasz Miąsko [Tue, 20 Oct 2020 00:00:00 +0000 (00:00 +0000)]
Disable MatchBranchSimplification
This optimization can result in unsoundness, because it introduces
additional uses of a place holding the discriminant value without
ensuring that it is valid to do so.
Tomasz Miąsko [Tue, 20 Oct 2020 00:00:00 +0000 (00:00 +0000)]
Check that pthread mutex initialization succeeded
If pthread mutex initialization fails, the failure will go unnoticed unless
debug assertions are enabled. Any subsequent use of mutex will also silently
fail, since return values from lock & unlock operations are similarly checked
only through debug assertions.
In some implementations the mutex initialization requires a memory
allocation and so it does fail in practice.
Check that initialization succeeds to ensure that mutex guarantees
mutual exclusion.
bors [Mon, 19 Oct 2020 17:53:17 +0000 (17:53 +0000)]
Auto merge of #78106 - GuillaumeGomez:rollup-06vwk7p, r=GuillaumeGomez
Rollup of 4 pull requests
Successful merges:
- #77877 (Use `try{}` in `try_fold` to decouple iterators in the library from `Try` details)
- #78089 (Fix issue with specifying generic arguments for primitive types)
- #78099 (Add missing punctuation)
- #78103 (Add link to rustdoc book in rustdoc help popup)
Guillaume Gomez [Mon, 19 Oct 2020 16:20:20 +0000 (18:20 +0200)]
Rollup merge of #77877 - scottmcm:fewer-try-trait-method-references, r=shepmaster
Use `try{}` in `try_fold` to decouple iterators in the library from `Try` details
I'd like to experiment with changing the `?`/`try` desugaring and correspondingly the `Try` trait (see #42327 for discussions about the suboptimalities of the current one) and this change would keep from needing any `cfg(bootstrap)` in iterator things.
This will be lowered to the same thing, so shouldn't cause any perf issues:
https://github.com/rust-lang/rust/blob/08e2d4616613716362b4b49980ff303f2b9ae654/compiler/rustc_ast_lowering/src/expr.rs#L428-L429
~~EDIT: changed to a draft because of the rustfmt-only syntax error. zulip thread about it: https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/New.20bootstrap.20rustfmt.20doesn't.20support.20syntax.20from.20sept.3F/near/213098097~~
EDIT: This now includes a rustfmt version bump to get through tidy.
bors [Sun, 18 Oct 2020 16:10:00 +0000 (16:10 +0000)]
Auto merge of #77306 - lcnr:inline-ok, r=eddyb
normalize substs while inlining
fixes #68347 or more precisely, this fixes the same ICE in rust analyser as veloren is pinned to a specific nightly
and had an error with the current one.
I didn't look into creating an MVCE here as that seems fairly annoying, will spend a few minutes doing so rn. (failed)
bors [Sun, 18 Oct 2020 11:19:14 +0000 (11:19 +0000)]
Auto merge of #78058 - bugadani:arena2, r=lcnr
Make sure arenas don't allocate bigger than HUGE_PAGE
Right now, arenas allocate based on the size of the last chunk. It is possible for a `grow` call to allocate a chunk that is not a multiple of `PAGE`, and this size is doubled for each subsequent allocation. This means, instead of `HUGE_PAGE`, the biggest page possible is actually unknown.
This change fixes this, and also removes an unnecessary checked multiplication. It is still possible to allocate bigger than `HUGE_PAGE` pages, but this will only happen as many times as absolutely necessary.
bors [Sun, 18 Oct 2020 05:36:23 +0000 (05:36 +0000)]
Auto merge of #78047 - khyperia:set_span_mut, r=bjorn3
Make set_span take mut self
This was a mistake in https://github.com/rust-lang/rust/pull/77614
It's not a _huge_ deal, because backends can always implement this with interior mutability, but it's nice to avoid interior mutability when possible. For context, the `set_source_location` method, called alongside `set_span`, also takes `&mut self`.
bors [Sun, 18 Oct 2020 02:28:21 +0000 (02:28 +0000)]
Auto merge of #74480 - yoshuawuyts:hardware_threads, r=dtolnay
Add std::thread::available_concurrency
This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust, tracking issue https://github.com/rust-lang/rust/issues/74479.
cc/ `@rust-lang/libs`
## Motivation
Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform.
__edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups, but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186.
## Naming
Discussing the naming of the API on Zulip surfaced two options:
Both options seemed acceptable, but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the "hardware threads" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20):
> A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__, or harts, through multithreading.
It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency`, so we can't use that to help inform our decision here.
## Return type
An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option<NonZeroUsize>` as its return type, where `None` is returned on platforms where we don't know the number of hardware threads available.
The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known, they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use, but improving the ergonomics of them is something that I think we can address separately.
## Implementation
`@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.
bors [Sun, 18 Oct 2020 00:19:24 +0000 (00:19 +0000)]
Auto merge of #77956 - JohnTitor:more-tests, r=nagisa
Add some more regression tests
This is another round of #77741. Tested with `debug-assertions=true` and it passed on my local.
Closes #70877
Closes #70944
Closes #71659
Closes #74816
Closes #75707
Closes #75983
(Skipped #63355 because I'm not sure about the error.)