bors [Sun, 12 Dec 2021 03:50:30 +0000 (03:50 +0000)]
Auto merge of #89404 - Kobzol:hash-stable-sort, r=Mark-Simulacrum
Slightly optimize hash map stable hashing
I was profiling some of the `rustc-perf` benchmarks locally and noticed that quite some time is spent inside the stable hash of hashmaps. I tried to use a `SmallVec` instead of a `Vec` there, which helped very slightly.
Then I tried to remove the sorting, which was a bottleneck, and replaced it with insertion into a binary heap. Locally, it yielded nice improvements in instruction counts and RSS in several benchmarks for incremental builds. The implementation could probably be much nicer and possibly extended to other stable hashes, but first I wanted to test the perf impact properly.
bors [Sun, 12 Dec 2021 00:58:30 +0000 (00:58 +0000)]
Auto merge of #91813 - matthiaskrgr:rollup-nryyeyj, r=matthiaskrgr
Rollup of 8 pull requests
Successful merges:
- #90081 (Make `intrinsics::write_bytes` const)
- #91643 (asm: Allow using r9 (ARM) and x18 (AArch64) if they are not reserved by the current target)
- #91737 (Make certain panicky stdlib functions behave better under panic_immediate_abort)
- #91750 (rustdoc: Add regression test for Iterator as notable trait on &T)
- #91764 (Do not ICE when suggesting elided lifetimes on non-existent spans.)
- #91780 (Remove hir::Node::hir_id.)
- #91797 (Fix zero-sized reference to deallocated memory)
- #91806 (Make `Unique`s methods `const`)
Matthias Krüger [Sat, 11 Dec 2021 22:31:51 +0000 (23:31 +0100)]
Rollup merge of #91750 - notriddle:notriddle/doc-notable_trait-mut_t_is_not_ref_t, r=Mark-Simulacrum
rustdoc: Add regression test for Iterator as notable trait on &T
Closes #78160
This regression test is different from the one in #91748, because while neither of these function should have Iterator marked as a notable trait, the reasons are different.
* In this PR, it returns `&T where T: Iterator`. The `mut` is what's missing.
* In #91748, it returns `&mut T`. The trait bounds are what's missing.
Matthias Krüger [Sat, 11 Dec 2021 22:31:50 +0000 (23:31 +0100)]
Rollup merge of #91737 - Manishearth:panic-immediate-stdlib, r=joshtriplett
Make certain panicky stdlib functions behave better under panic_immediate_abort
The stdlib has a `panic_immediate_abort` feature that turns panics into immediate aborts, without any formatting/display logic. This feature was [introduced](https://github.com/rust-lang/rust/pull/55011) primarily for codesize-constrained situations.
Unfortunately, this win doesn't quite propagate to `Result::expect()` and `Result::unwrap()`, while the formatting machinery is reduced, `expect()` and `unwrap()` both call `unwrap_failed("msg", &err)` which has a signature of `fn unwrap_failed(msg: &str, error: &dyn fmt::Debug)` and is `#[inline(never)]`. This means that `unwrap_failed` will unconditionally construct a `dyn Debug` trait object even though the object is never used in the function.
Constructing a trait object (even if you never call a method on it!) forces rust to include the vtable and any dependencies. This means that in `panic_immediate_abort` mode, calling expect/unwrap on a Result will pull in a whole bunch of formatting code for the error type even if it's completely unused.
This PR swaps out the function with one that won't require a trait object such that it won't force the inclusion of vtables in the code. It also gates off `#[inline(never)]` in a bunch of other places where allowing the inlining of an abort may be useful (this kind of thing is already done elsewhere in the stdlib).
I don't know how to write a test for this; we don't really seem to have any tests for `panic_immediate_abort` anyway so perhaps it's fine as is.
bors [Sat, 11 Dec 2021 21:57:19 +0000 (21:57 +0000)]
Auto merge of #91769 - estebank:type-trait-bound-span-2, r=oli-obk
Tweak assoc type obligation spans
* Point at RHS of associated type in obligation span
* Point at `impl` assoc type on projection error
* Reduce verbosity of recursive obligations
* Point at source of binding lifetime obligation
* Tweak "required bound" note
* Tweak "expected... found opaque (return) type" labels
* Point at set type in impl assoc type WF errors
Matthias Krüger [Sat, 11 Dec 2021 16:35:27 +0000 (17:35 +0100)]
Rollup merge of #91721 - danielhenrymantilla:patch-1, r=joshtriplett
Minor improvements to `future::join!`'s implementation
This is a follow-up from #91645, regarding [some remarks I made](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/join!/near/264293660).
Mainly:
- it hides the recursive munching through a private `macro`, to avoid leaking such details (a corollary is getting rid of the need to use ``@`` to disambiguate);
- it uses a `match` binding, _outside_ the `async move` block, to better match the semantics from function-like syntax;
- it pre-pins the future before calling into `poll_fn`, since `poll_fn`, alone, cannot guarantee that its capture does not move (to clarify: I believe the previous code was sound, thanks to the outer layer of `async`. But I find it clearer / more robust to refactorings this way 🙂).
- it uses `@ibraheemdev's` very neat `.ready()?`;
- it renames `Took` to `Taken` for consistency with `Done` (tiny nit 😄).
~~TODO~~Done:
- [x] Add unit tests to enforce the function-like `:value` semantics are respected.
Matthias Krüger [Sat, 11 Dec 2021 16:35:26 +0000 (17:35 +0100)]
Rollup merge of #91548 - luojia65:hint-spin-loop-riscv, r=Amanieu
Add spin_loop hint for RISC-V architecture
This commit uses the PAUSE instruction (https://github.com/rust-lang/stdarch/pull/1262) to implement RISC-V spin loop, and updates `stdarch` submodule to use the merged PAUSE instruction.
Matthias Krüger [Sat, 11 Dec 2021 16:35:23 +0000 (17:35 +0100)]
Rollup merge of #89734 - estebank:issue-72312, r=nikomatsakis
Point at capture points for non-`'static` reference crossing a `yield` point
```
error[E0759]: `self` has an anonymous lifetime `'_` but it needs to satisfy a `'static` lifetime requirement
--> $DIR/issue-72312.rs:10:24
|
LL | pub async fn start(&self) {
| ^^^^^ this data with an anonymous lifetime `'_`...
...
LL | require_static(async move {
| -------------- ...is required to live as long as `'static` here...
LL | &self;
| ----- ...and is captured here
|
note: `'static` lifetime requirement introduced by this trait bound
--> $DIR/issue-72312.rs:2:22
|
LL | fn require_static<T: 'static>(val: T) -> T {
| ^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0759`.
```
Matthias Krüger [Sat, 11 Dec 2021 16:35:23 +0000 (17:35 +0100)]
Rollup merge of #83174 - camelid:borrow-help, r=oli-obk
Suggest using a temporary variable to fix borrowck errors
Fixes #77834.
In Rust, nesting method calls with both require `&mut` access to `self`
produces a borrow-check error:
error[E0499]: cannot borrow `*self` as mutable more than once at a time
--> src/lib.rs:7:14
|
7 | self.foo(self.bar());
| ---------^^^^^^^^^^-
| | | |
| | | second mutable borrow occurs here
| | first borrow later used by call
| first mutable borrow occurs here
That's because Rust has a left-to-right evaluation order, and the method
receiver is passed first. Thus, the argument to the method cannot then
mutate `self`.
There's an easy solution to this error: just extract a local variable
for the inner argument:
let tmp = self.bar();
self.foo(tmp);
However, the error doesn't give any suggestion of how to solve the
problem. As a result, new users may assume that it's impossible to
express their code correctly and get stuck.
This commit adds a (non-structured) suggestion to extract a local
variable for the inner argument to solve the error. The suggestion uses
heuristics that eliminate most false positives, though there are a few
false negatives (cases where the suggestion should be emitted but is
not). Those other cases can be implemented in a future change.
bors [Sat, 11 Dec 2021 15:55:22 +0000 (15:55 +0000)]
Auto merge of #91792 - matthiaskrgr:rollup-2epg7jq, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #91617 (Improve the readability of `List<T>`.)
- #91640 (Simplify collection of in-band lifetimes)
- #91682 (rustdoc: Show type layout for type aliases)
- #91711 (Improve `std::iter::zip` example)
- #91717 (Add deprecation warning for --passes)
- #91718 (give more help in the unaligned_references lint)
- #91782 (Correct since attribute for `is_symlink` feature)
Matthias Krüger [Sat, 11 Dec 2021 15:02:47 +0000 (16:02 +0100)]
Rollup merge of #91682 - camelid:alias-layout, r=jyn514
rustdoc: Show type layout for type aliases
Fixes #91265.
At first, you might think, "Why not just click through to the aliased
type?" But, if a type alias instantiates all of the generic parameters
of the aliased type, then it can show layout info even though the
aliased type cannot (because we can't compute layout for generic types).
So, I think it's useful to show layout info for type aliases.
Matthias Krüger [Sat, 11 Dec 2021 15:02:45 +0000 (16:02 +0100)]
Rollup merge of #91617 - nnethercote:improve-List-readability, r=lcnr
Improve the readability of `List<T>`.
This commit does the following.
- Expands on some of the things already mentioned in comments.
- Describes the uniqueness assumption, which is critical but wasn't
mentioned at all.
- Rewrites `empty()` into a clearer form, as provided by Daniel
Henry-Mantilla on Zulip.
- Reorders things slightly so that more important things
are higher up, and incidental things are lower down, which makes
reading the code easier.
bors [Sat, 11 Dec 2021 10:37:52 +0000 (10:37 +0000)]
Auto merge of #91776 - matthiaskrgr:rollup-tlb4bw1, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #91127 (Add `<*{const|mut} T>::{to|from}_bits`)
- #91310 (Add --out-dir flag for rustdoc)
- #91373 (Add needs-unwind to tests that depend on panicking)
- #91426 (Make IdFunctor::try_map_id panic-safe)
- #91515 (Add rsplit_array variants to slices and arrays)
- #91553 (socket ancillary data implementation for dragonflybsd.)
Matthias Krüger [Sat, 11 Dec 2021 07:22:31 +0000 (08:22 +0100)]
Rollup merge of #91373 - djkoloski:fuchsia_test_suite, r=Mark-Simulacrum
Add needs-unwind to tests that depend on panicking
These tests were found by running the test suite on fuchsia which compiles with `panic=abort` by default, then picking through the failures manually to locate the tests that require unwinding support.
Most of these tests are already opted-out on platforms that compile with `panic=abort` by default. This just generalizes it a bit more so that fuchsia tests can be run properly. Currently, the `needs-unwind` directive needs to be manually passed to compiletest (e.g. via `--test-args '--target-panic=abort'`). Eventually, I would like `x.py` or compiletest to determine whether the directive should be used automatically based on the target panic settings.
Matthias Krüger [Sat, 11 Dec 2021 07:22:30 +0000 (08:22 +0100)]
Rollup merge of #91310 - hi-rustin:rustin-patch-rustdoc, r=jyn514
Add --out-dir flag for rustdoc
part of https://github.com/rust-lang/rust/issues/91260
Add --out-dir flag for rustdoc and change the `-o` option to point to out-dir.
I'm not quite sure if it should be stable, also I'm not sure if this parameter priority is appropriate? Or should I just refuse to pass both parameters at the same time?
Based on the conversation in https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20methods.20as.20more.20specific.20versions.20of.20.60as.60/near/238391074
bors [Sat, 11 Dec 2021 03:52:12 +0000 (03:52 +0000)]
Auto merge of #91761 - matthiaskrgr:rollup-bjowmvz, r=matthiaskrgr
Rollup of 11 pull requests
Successful merges:
- #91668 (Remove the match on `ErrorKind::Other`)
- #91678 (Add tests fixed by #90023)
- #91679 (Move core/stream/stream/mod.rs to core/stream/stream.rs)
- #91681 (fix typo in `intrinsics::raw_eq` docs)
- #91686 (Fix `Vec::reserve_exact` documentation)
- #91697 (Delete Utf8Lossy::from_str)
- #91706 (Add unstable book entries for parts of asm that are not being stabilized)
- #91709 (Replace iterator-based set construction by *Set::From<[T; N]>)
- #91716 (Improve x.py logging and defaults a bit more)
- #91747 (Add pierwill to .mailmap)
- #91755 (Fix since attribute for const_linked_list_new feature)
Esteban Kuber [Sat, 11 Dec 2021 02:20:41 +0000 (02:20 +0000)]
Tweak assoc type obligation spans
* Point at RHS of associated type in obligation span
* Point at `impl` assoc type on projection error
* Reduce verbosity of recursive obligations
* Point at source of binding lifetime obligation
* Tweak "required bound" note
* Tweak "expected... found opaque (return) type" labels
* Point at set type in impl assoc type WF errors
bors [Sat, 11 Dec 2021 01:00:14 +0000 (01:00 +0000)]
Auto merge of #91715 - the8472:bump-rmeta-fromat-version, r=Mark-Simulacrum
Bump rmeta version to fix rustc_serialize ICE
#91407 changed the serialization format which leads to ICEs for nightly users such as #91663 and linked issues. The issue can be solved by running `cargo clean`. But bumping the metadata version should lead to the cached files being discarded, avoiding the issue entirely.
Noah Lev [Mon, 15 Mar 2021 22:09:06 +0000 (15:09 -0700)]
Suggest using a temporary variable to fix borrowck errors
In Rust, nesting method calls with both require `&mut` access to `self`
produces a borrow-check error:
error[E0499]: cannot borrow `*self` as mutable more than once at a time
--> src/lib.rs:7:14
|
7 | self.foo(self.bar());
| ---------^^^^^^^^^^-
| | | |
| | | second mutable borrow occurs here
| | first borrow later used by call
| first mutable borrow occurs here
That's because Rust has a left-to-right evaluation order, and the method
receiver is passed first. Thus, the argument to the method cannot then
mutate `self`.
There's an easy solution to this error: just extract a local variable
for the inner argument:
let tmp = self.bar();
self.foo(tmp);
However, the error doesn't give any suggestion of how to solve the
problem. As a result, new users may assume that it's impossible to
express their code correctly and get stuck.
This commit adds a (non-structured) suggestion to extract a local
variable for the inner argument to solve the error. The suggestion uses
heuristics that eliminate most false positives, though there are a few
false negatives (cases where the suggestion should be emitted but is
not). Those other cases can be implemented in a future change.
bors [Fri, 10 Dec 2021 21:59:07 +0000 (21:59 +0000)]
Auto merge of #91760 - matthiaskrgr:rollup-zcemh6j, r=matthiaskrgr
Rollup of 10 pull requests
Successful merges:
- #90407 (Document all public items in `rustc_incremental`)
- #90897 (Fix incorrect stability attributes)
- #91105 (Fix method name reference in stream documentation)
- #91325 (adjust const_eval_select documentation)
- #91470 (code-cov: generate dead functions with private/default linkage)
- #91482 (Update documentation to use `from()` to initialize `HashMap`s and `BTreeMap`s)
- #91524 (Fix Vec::extend_from_slice docs)
- #91575 (Fix ICE on format string of macro with secondary-label)
- #91625 (Remove redundant [..]s)
- #91646 (Fix documentation for `core::ready::Ready`)
Matthias Krüger [Fri, 10 Dec 2021 21:41:28 +0000 (22:41 +0100)]
Rollup merge of #91709 - juniorbassani:use-from-array-in-set-examples, r=jyn514
Replace iterator-based set construction by *Set::From<[T; N]>
This uses the array-based construction for `BtreeSet`s and `HashSet`s instead of first creating an iterator. I could also replace the `let mut a = Set::new(); a.insert(...);` fragments if desired.
Matthias Krüger [Fri, 10 Dec 2021 21:41:26 +0000 (22:41 +0100)]
Rollup merge of #91697 - dtolnay:lossyfromstr, r=Mark-Simulacrum
Delete Utf8Lossy::from_str
This whole type is marked as being for str internals only, but this constructor is never used by str internals. If you had a &str already and wanted to lossy display it or iterate its lossy utf8 chunks, you would simply not use Utf8Lossy because the whole &str is known to be one contiguous valid utf8 chunk.
If code really does need to obtain a value of type &Utf8Lossy somewhere, and has only a &str, `Utf8Lossy::from_bytes(s.as_bytes())` remains available. As currently implemented, there is no performance penalty relative to `from_str` i.e. the Utf8Lossy does not "remember" that it was constructed using `from_str` to bypass later utf8 decoding.
Matthias Krüger [Fri, 10 Dec 2021 21:40:35 +0000 (22:40 +0100)]
Rollup merge of #91575 - compiler-errors:issue-91556, r=cjgillot
Fix ICE on format string of macro with secondary-label
This generalizes the fix #86104 to also correctly skip `Span::from_inner` for the `secondary_label` of a format macro parsing error as well.
We can alternatively skip the `span_label` diagnostic call for the secondary label as well, since that label probably only makes sense when the _proper_ span is computed.
Matthias Krüger [Fri, 10 Dec 2021 21:40:33 +0000 (22:40 +0100)]
Rollup merge of #91482 - JosephTLyons:update-HashMap-and-BTreeMap-documentation, r=yaahc
Update documentation to use `from()` to initialize `HashMap`s and `BTreeMap`s
As of Rust 1.56, `HashMap` and `BTreeMap` both have associated `from()` functions. I think using these in the documentation cleans things up a bit. It allows us to remove some of the `mut`s and avoids the Initialize-Then-Modify anti-pattern.
Matthias Krüger [Fri, 10 Dec 2021 21:40:32 +0000 (22:40 +0100)]
Rollup merge of #91470 - wesleywiser:code_coverage_link_error, r=tmandry
code-cov: generate dead functions with private/default linkage
As discovered in #85461, the MSVC linker treats weak symbols slightly
differently than unix-y linkers do. This causes link.exe to fail with
LNK1227 "conflicting weak extern definition" where as other targets are
able to link successfully.
This changes the dead functions from being generated as weak/hidden to
private/default which, as the LLVM reference says:
> Global values with “private” linkage are only directly accessible by
objects in the current module. In particular, linking code into a module
with a private global value may cause the private to be renamed as
necessary to avoid collisions. Because the symbol is private to the
module, all references can be updated. This doesn’t show up in any
symbol table in the object file.
This fixes the conflicting weak symbols but doesn't address the reason
*why* we have conflicting symbols for these dead functions. The test
cases added in this commit contain a minimal repro of the fundamental
issue which is that the logic used to decide what dead code functions
should be codegen'd in the current CGU doesn't take into account that
functions can be duplicated across multiple CGUs (for instance, in the
case of `#[inline(always)]` functions).
Fixing that is likely to be a more complex change (see
https://github.com/rust-lang/rust/issues/85461#issuecomment-985005805).
Matthias Krüger [Fri, 10 Dec 2021 21:40:32 +0000 (22:40 +0100)]
Rollup merge of #91325 - RalfJung:const_eval_select, r=dtolnay
adjust const_eval_select documentation
"The Rust compiler assumes" indicates that this is language UB, but [I don't think that is a good idea](https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/const_eval_select.20assumptions). This UB would be very hard to test for and looks like a way-too-big footgun. ``@oli-obk`` suggested this is meant to be more like "library UB", so I tried to adjust the docs accordingly.
I also removed all references to "referential transparency". That is a rather vague concept used to mean many different things, and I honestly have no idea what exactly is meant by it in this specific instance. But I assume ``@fee1-dead`` had in their mind a property that all `const fn` code upholds, so by demanding that the runtime code and the const-time code are *observably equivalent*, whatever that property is would also be enforced here.
Esteban Kuber [Sun, 10 Oct 2021 10:37:57 +0000 (10:37 +0000)]
Point at capture points for non-`'static` reference crossing a `yield` point
```
error[E0759]: `self` has an anonymous lifetime `'_` but it needs to satisfy a `'static` lifetime requirement
--> $DIR/issue-72312.rs:10:24
|
LL | pub async fn start(&self) {
| ^^^^^ this data with an anonymous lifetime `'_`...
...
LL | require_static(async move {
| -------------- ...is required to live as long as `'static` here...
LL | &self;
| ----- ...and is captured here
|
note: `'static` lifetime requirement introduced by this trait bound
--> $DIR/issue-72312.rs:2:22
|
LL | fn require_static<T: 'static>(val: T) -> T {
| ^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0759`.
```
Minor improvements to `future::join!`'s implementation
This is a follow-up from #91645, regarding [some remarks I made](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/join!/near/264293660).
Mainly:
- it hides the recursive munching through a private `macro`, to avoid leaking such details (a corollary is getting rid of the need to use `@` to disambiguate);
- it uses a `match` binding, _outside_ the `async move` block, to better match the semantics from function-like syntax;
- it pre-pins the future before calling into `poll_fn`, since `poll_fn`, alone, cannot guarantee that its capture does not move;
- it uses `.ready()?` since it's such a neat pattern;
- it renames `Took` to `Taken` for consistency with `Done`.
projects / rust.git / log