bors [Thu, 6 Oct 2022 19:55:48 +0000 (19:55 +0000)]
Auto merge of #102741 - matthiaskrgr:rollup-63no5tz, r=matthiaskrgr
Rollup of 5 pull requests
Successful merges:
- #98496 (make `compare_const_impl` a query and use it in `instance.rs`)
- #102680 (Fix overconstrained Send impls in btree internals)
- #102718 (Fix `opaque_hidden_inferred_bound` lint ICE)
- #102725 (Remove `-Ztime`)
- #102736 (Migrate search input color to CSS variable)
I am not familiar with the btree internals, but it seems clear to me that the `async fn f` above should return a Send future. Using HashMap instead of BTreeMap in that code makes it already return a Send future.
The _"higher-ranked lifetime error"_ message may be a regression in Rust 1.63. Using older compilers the error message was more detailed:
```console
error: implementation of `Send` is not general enough
--> src/main.rs:14:5
|
14 | spawn(f());
| ^^^^^ implementation of `Send` is not general enough
|
= note: `Send` would have to be implemented for the type `alloc::collections::btree::node::NodeRef<alloc::collections::btree::node::marker::Immut<'0>, u32, Box<(dyn Send + Sync + '1)>, alloc::collections::btree::node::marker::LeafOrInternal>`, for any two lifetimes `'0` and `'1`...
= note: ...but `Send` is actually implemented for the type `alloc::collections::btree::node::NodeRef<alloc::collections::btree::node::marker::Immut<'2>, u32, Box<dyn Send + Sync>, alloc::collections::btree::node::marker::LeafOrInternal>`, for some specific lifetime `'2`
error: implementation of `Send` is not general enough
--> src/main.rs:14:5
|
14 | spawn(f());
| ^^^^^ implementation of `Send` is not general enough
|
= note: `Send` would have to be implemented for the type `alloc::collections::btree::node::NodeRef<alloc::collections::btree::node::marker::Immut<'0>, u32, Box<(dyn Send + Sync + '1)>, alloc::collections::btree::node::marker::Leaf>`, for any two lifetimes `'0` and `'1`...
= note: ...but `Send` is actually implemented for the type `alloc::collections::btree::node::NodeRef<alloc::collections::btree::node::marker::Immut<'2>, u32, Box<dyn Send + Sync>, alloc::collections::btree::node::marker::Leaf>`, for some specific lifetime `'2`
```
Matthias Krüger [Thu, 6 Oct 2022 14:29:43 +0000 (16:29 +0200)]
Rollup merge of #98496 - BoxyUwU:instancers_bad_equality, r=lcnr
make `compare_const_impl` a query and use it in `instance.rs`
Fixes #88365
the bug in #88365 was caused by some `instance.rs` code using the `PartialEq` impl on `Ty` to check that the type of the associated const in an impl is the same as the type of the associated const in the trait definition. This was wrong for two reasons:
- the check typeck does is that the impl type is a subtype of the trait definition's type (see `mismatched_impl_ty_2.rs` which [was ICEing](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f6d60ebe6745011f0d52ab2bc712025d) before this PR on stable)
- it assumes that if two types are equal then the `PartialEq` impl will reflect that which isnt true for higher ranked types or type level constants when `feature(generic_const_exprs)` is enabled (see `mismatched_impl_ty_3.rs` for higher ranked types which was [ICEing on stable](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d7af131a655ed515b035624626c62c71))
bors [Thu, 6 Oct 2022 08:58:01 +0000 (08:58 +0000)]
Auto merge of #102707 - fmease:rustdoc-render-more-cross-crate-hrtbs-properly, r=GuillaumeGomez
rustdoc: render more cross-crate HRTBs properly
Follow-up to #102439.
Render the `for<>` parameter lists of cross-crate higher-rank trait bounds (in where-clauses and in `impl Trait`).
I've added a new field `bound_params` to `clean::WherePredicate::EqPredicate` (mirroring its sibling variant `BoundPredicate`). However, I had to box the existing fields since `EqPredicate` used to be the largest variant (128 bytes on 64-bit systems) and it would only have gotten bigger).
Not sure if you like that approach. As an alternative, I could pass the uncleaned `ty::Predicate` alongside the cleaned `WherePredicate` to the various re-sugaring methods (similar to what `clean::AutoTraitFinder::param_env_to_generics` does).
I haven't yet added the HTML & JSON rendering code for the newly added `bound_params` field since I am waiting for your opinion. Those two rendering code paths should actually be unreachable in practice given we re-sugar all(?) equality predicates to associated type bindings (and arbitrary equality predicates are not part of the Rust surface language at the time of this writing).
If you agree with storing `bound_params` in `EqPredicate`, I think I can use it to greatly simplify the `clean::auto_trait` module (by also using `simplify::merge_bounds`). Maybe I can do that in any case though.
bors [Thu, 6 Oct 2022 05:58:27 +0000 (05:58 +0000)]
Auto merge of #102726 - matthiaskrgr:rollup-2ghn38b, r=matthiaskrgr
Rollup of 5 pull requests
Successful merges:
- #102672 (rustdoc: remove unused CSS class `in-band`)
- #102693 (Revert "Use getentropy when possible on all Apple platforms")
- #102694 (Suggest calling method if fn does not exist)
- #102708 (Suggest `==` to wrong assign expr)
- #102710 (Add test for issue 82633)
Matthias Krüger [Thu, 6 Oct 2022 05:07:37 +0000 (07:07 +0200)]
Rollup merge of #102710 - Rageking8:add-test-for-issue-82633, r=estebank
Add test for issue 82633
Fixes #82633
r? `@estebank`
The current stderr looks slightly different from [source](https://github.com/rust-lang/rust/pull/83915/files#diff-8c64c576ccaceb816e71d2279a6ee4bf79211bc06f55c46dda3f98a18748ad7a), so I used the latest one from nightly. Do let me know if anything is wrong.
Matthias Krüger [Thu, 6 Oct 2022 05:07:37 +0000 (07:07 +0200)]
Rollup merge of #102708 - TaKO8Ki:improve-eqeq-suggestion, r=estebank
Suggest `==` to wrong assign expr
Given the following code:
```rust
fn main() {
let x = 3;
let y = 3;
if x == x && y = y {
println!("{}", x);
}
}
```
Current output is:
```
error[E0308]: mismatched types
--> src/main.rs:4:18
|
4 | if x == x && y = y {
| ^ expected `bool`, found integer
error[E0308]: mismatched types
--> src/main.rs:4:8
|
4 | if x == x && y = y {
| ^^^^^^^^^^^^^^^ expected `bool`, found `()`
```
This adds a suggestion:
```diff
error[E0308]: mismatched types
--> src/main.rs:6:18
|
6 | if x == x && y = y {
| ^ expected `bool`, found integer
error[E0308]: mismatched types
--> src/main.rs:6:8
|
6 | if x == x && y = y {
| ^^^^^^^^^^^^^^^ expected `bool`, found `()`
|
+ help: you might have meant to compare for equality
+ |
+ 6 | if x == x && y == y {
+ | +
```
Matthias Krüger [Thu, 6 Oct 2022 05:07:36 +0000 (07:07 +0200)]
Rollup merge of #102694 - compiler-errors:fn-to-method, r=davidtwco
Suggest calling method if fn does not exist
I tried to split this up into two commits, the first where we stash the resolution error until typeck (which causes a bunch of diagnostics changes because the ordering of error messages change), then the second commit is the actual logic that actually implements the suggestion.
I am not in love with the presentation of the suggestion, so I could use some advice for how to format the actual messaging.
Since all of these uses are nested below `h1.fqn`, we can get rid of it, and the support code that was used for when `in-band` was part of item rendering.
Be consistent about deciding whether to print pass data.
`print_time_passes_entry` unconditionally prints data about a pass. The
most commonly used call site, in `VerboseTimingGuard::drop`, guards it
with a `should_print_passes` test. But there are a couple of other call
sites that don't do that test.
This commit moves the `should_print_passes` test within
`print_time_passes_entry` so that all passes are treated equally.
The compiler currently has `-Ztime` and `-Ztime-passes`. I've used
`-Ztime-passes` for years but only recently learned about `-Ztime`.
What's the difference? Let's look at the `-Zhelp` output:
```
-Z time=val -- measure time of rustc processes (default: no)
-Z time-passes=val -- measure time of each rustc pass (default: no)
```
The `-Ztime-passes` description is clear, but the `-Ztime` one is less so.
Sounds like it measures the time for the entire process?
No. The real difference is that `-Ztime-passes` prints out info about passes,
and `-Ztime` does the same, but only for a subset of those passes. More
specifically, there is a distinction in the profiling code between a "verbose
generic activity" and an "extra verbose generic activity". `-Ztime-passes`
prints both kinds, while `-Ztime` only prints the first one. (It took me
a close reading of the source code to determine this difference.)
In practice this distinction has low value. Perhaps in the past the "extra
verbose" output was more voluminous, but now that we only print stats for a
pass if it exceeds 5ms or alters the RSS, `-Ztime-passes` is less spammy. Also,
a lot of the "extra verbose" cases are for individual lint passes, and you need
to also use `-Zno-interleave-lints` to see those anyway.
Therefore, this commit removes `-Ztime` and the associated machinery. One thing
to note is that the existing "extra verbose" activities all have an extra
string argument, so the commit adds the ability to accept an extra argument to
the "verbose" activities.
bors [Thu, 6 Oct 2022 00:00:29 +0000 (00:00 +0000)]
Auto merge of #102573 - RalfJung:mirisync, r=oli-obk
Miri sync
This is a Miri sync created with my experimental fork of josh. We should probably not merge this yet, but we can use this to check if the sync looks the way it should.
Since all of these uses are nested below `h1.fqn`, we can get rid of it,
and the support code that was used for when `in-band` was part of item
rendering.
bors [Wed, 5 Oct 2022 20:47:39 +0000 (20:47 +0000)]
Auto merge of #102394 - dingxiangfei2009:issue-102317, r=oli-obk
Fix unwind drop glue for if-then scopes
cc `@est31`
Fix #102317
Fix #99852
This PR fixes the drop glue for unwinding from a panic originated in a drop while breaking out for the else block in an `if-then` scope.
MIR validation does not fail for the synchronous versions of the test program, because `StorageDead` statements are skipped over in the unwinding process. It is only becoming a problem when it is inside a generator where `StorageDead` must be kept around.
error: implementation of `Send` is not general enough
--> library/alloc/tests/autotraits.rs:56:5
|
56 | / require_send_sync(async {
57 | | let _v = None::<
58 | | alloc::collections::btree_map::DrainFilter<
59 | | '_,
... |
65 | | async {}.await;
66 | | });
| |______^ implementation of `Send` is not general enough
|
= note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
= note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`
error: implementation of `Send` is not general enough
--> library/alloc/tests/autotraits.rs:68:5
|
68 | / require_send_sync(async {
69 | | let _v = None::<alloc::collections::btree_map::Entry<'_, &u32, &u32>>;
70 | | async {}.await;
71 | | });
| |______^ implementation of `Send` is not general enough
|
= note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
= note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`
error: implementation of `Send` is not general enough
--> library/alloc/tests/autotraits.rs:93:5
|
93 | / require_send_sync(async {
94 | | let _v = None::<alloc::collections::btree_map::IterMut<'_, &u32, &u32>>;
95 | | async {}.await;
96 | | });
| |______^ implementation of `Send` is not general enough
|
= note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
= note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`
error: implementation of `Send` is not general enough
--> library/alloc/tests/autotraits.rs:103:5
|
103 | / require_send_sync(async {
104 | | let _v = None::<alloc::collections::btree_map::OccupiedEntry<'_, &u32, &u32>>;
105 | | async {}.await;
106 | | });
| |______^ implementation of `Send` is not general enough
|
= note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
= note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`
error: implementation of `Send` is not general enough
--> library/alloc/tests/autotraits.rs:108:5
|
108 | / require_send_sync(async {
109 | | let _v = None::<alloc::collections::btree_map::OccupiedError<'_, &u32, &u32>>;
110 | | async {}.await;
111 | | });
| |______^ implementation of `Send` is not general enough
|
= note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
= note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`
error: implementation of `Send` is not general enough
--> library/alloc/tests/autotraits.rs:118:5
|
118 | / require_send_sync(async {
119 | | let _v = None::<alloc::collections::btree_map::RangeMut<'_, &u32, &u32>>;
120 | | async {}.await;
121 | | });
| |______^ implementation of `Send` is not general enough
|
= note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
= note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`
error: implementation of `Send` is not general enough
--> library/alloc/tests/autotraits.rs:123:5
|
123 | / require_send_sync(async {
124 | | let _v = None::<alloc::collections::btree_map::VacantEntry<'_, &u32, &u32>>;
125 | | async {}.await;
126 | | });
| |______^ implementation of `Send` is not general enough
|
= note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
= note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`
error: implementation of `Send` is not general enough
--> library/alloc/tests/autotraits.rs:133:5
|
133 | / require_send_sync(async {
134 | | let _v = None::<alloc::collections::btree_map::ValuesMut<'_, &u32, &u32>>;
135 | | async {}.await;
136 | | });
| |______^ implementation of `Send` is not general enough
|
= note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
= note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`
error: implementation of `Send` is not general enough
--> library/alloc/tests/autotraits.rs:151:5
|
151 | / require_send_sync(async {
152 | | let _v = None::<alloc::collections::btree_set::DrainFilter<'_, &u32, fn(&&u32) -> bool>>;
153 | | async {}.await;
154 | | });
| |______^ implementation of `Send` is not general enough
|
= note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
= note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`
error: future cannot be sent between threads safely
--> library/alloc/tests/autotraits.rs:243:23
|
243 | require_send_sync(async {
| _______________________^
244 | | let _v =
245 | | None::<alloc::collections::linked_list::DrainFilter<'_, &u32, fn(&mut &u32) -> bool>>;
246 | | async {}.await;
247 | | });
| |_____^ future created by async block is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `NonNull<std::collections::linked_list::Node<&u32>>`
note: future is not `Send` as this value is used across an await
--> library/alloc/tests/autotraits.rs:246:17
|
244 | let _v =
| -- has type `Option<std::collections::linked_list::DrainFilter<'_, &u32, for<'a, 'b> fn(&'a mut &'b u32) -> bool>>` which is not `Send`
245 | None::<alloc::collections::linked_list::DrainFilter<'_, &u32, fn(&mut &u32) -> bool>>;
246 | async {}.await;
| ^^^^^^ await occurs here, with `_v` maybe used later
247 | });
| - `_v` is later dropped here
note: required by a bound in `require_send_sync`
--> library/alloc/tests/autotraits.rs:3:25
|
3 | fn require_send_sync<T: Send + Sync>(_: T) {}
| ^^^^ required by this bound in `require_send_sync`
error: future cannot be shared between threads safely
--> library/alloc/tests/autotraits.rs:243:23
|
243 | require_send_sync(async {
| _______________________^
244 | | let _v =
245 | | None::<alloc::collections::linked_list::DrainFilter<'_, &u32, fn(&mut &u32) -> bool>>;
246 | | async {}.await;
247 | | });
| |_____^ future created by async block is not `Sync`
|
= help: within `impl Future<Output = ()>`, the trait `Sync` is not implemented for `NonNull<std::collections::linked_list::Node<&u32>>`
note: future is not `Sync` as this value is used across an await
--> library/alloc/tests/autotraits.rs:246:17
|
244 | let _v =
| -- has type `Option<std::collections::linked_list::DrainFilter<'_, &u32, for<'a, 'b> fn(&'a mut &'b u32) -> bool>>` which is not `Sync`
245 | None::<alloc::collections::linked_list::DrainFilter<'_, &u32, fn(&mut &u32) -> bool>>;
246 | async {}.await;
| ^^^^^^ await occurs here, with `_v` maybe used later
247 | });
| - `_v` is later dropped here
note: required by a bound in `require_send_sync`
--> library/alloc/tests/autotraits.rs:3:32
|
3 | fn require_send_sync<T: Send + Sync>(_: T) {}
| ^^^^ required by this bound in `require_send_sync`
bors [Wed, 5 Oct 2022 17:54:32 +0000 (17:54 +0000)]
Auto merge of #102438 - andrewpollack:add-target-rustc-flags, r=Mark-Simulacrum
Adding target_rustcflags to `compiletest` TargetCfg creation
Adjustment to https://github.com/rust-lang/rust/pull/102134, ensures config returned by `rustc --target foo --print cfg` accurately reflects rustflags passed via `target_rustcflags`.
Fixes breaking change of not correctly handling `x.py test ... --test-args "--target-rustcflags -Cpanic=abort --target-rustcflags -Zpanic_abort_tests"`
Dylan DPC [Wed, 5 Oct 2022 11:57:33 +0000 (17:27 +0530)]
Rollup merge of #102496 - compiler-errors:into-suggestion, r=davidtwco
Suggest `.into()` when all other coercion suggestions fail
Also removes some bogus suggestions because we now short-circuit when offering coercion suggestions(instead of, for example, suggesting every one that could possibly apply)
Dylan DPC [Wed, 5 Oct 2022 11:57:33 +0000 (17:27 +0530)]
Rollup merge of #102440 - sunfishcode:sunfishcode/wasm-no-export-tls-api, r=oli-obk
Only export `__tls_*` on wasm32-unknown-unknown.
From talking with `@abrown,` we aren't planning to have hosts call these `__tls_*` functions; instead, TLS initialization will be handled transparently within libc. Consequently, these functions don't need to be exported.
Leave them exported on wasm32-unknown-unknown though, as wasm-bindgen does call them.
Dylan DPC [Wed, 5 Oct 2022 11:57:32 +0000 (17:27 +0530)]
Rollup merge of #101061 - RalfJung:panic-on-uninit, r=oli-obk
panic-on-uninit: adjust checks to 0x01-filling
Now that `mem::uninitiailized` actually fills memory with `0x01` (https://github.com/rust-lang/rust/pull/99182), we can make it panic in a few less cases without risking a lot more UB -- which hopefully slightly improves compatibility with some old code, and which might increase the chance that we can check inside arrays in the future.
We detect almost all of these with our lint, so authors of such code should still be warned -- but if this happens deep inside a dependency, the panic can be quite interruptive, so it might be better not to do it when there is no risk of LLVM UB. Therefore, adjust the `might_permit_raw_init` logic to care primarily about LLVM UB. To my knowledge, it actually covers all cases of LLVM UB now.
bors [Wed, 5 Oct 2022 11:41:40 +0000 (11:41 +0000)]
Auto merge of #98736 - alex:lipo-magic, r=bjorn3
resolve error when attempting to link a universal library on macOS
Previously attempting to link universal libraries into libraries (but not binaries) would produce an error that "File too small to be an archive". This works around this by invoking `lipo -thin` to extract a library for the target platform when passed a univeral library.
Fixes #55235
It's worth acknowledging that this implementation is kind of a horrible hack. Unfortunately I don't know how to do anything better, hopefully this PR will be a jumping off point.
Michael Howell [Wed, 5 Oct 2022 03:45:13 +0000 (20:45 -0700)]
Rollup merge of #102650 - Rageking8:slightly-improve-no-return-for-returning-function-error, r=compiler-errors
Slightly improve no return for returning function error
Fixes #100607
The rationale is that absolute beginners will be slightly confused as to why certain lines of code in a function does not require a semicolon. (I have actually witness a beginner having this confusion). Hence, a slight rationale is added "to return this value", which signals to the user that after removing said semicolon the value is returned resolving that error.
However, if this is not desirable, I welcome any other suggestions. Thanks.
Michael Howell [Wed, 5 Oct 2022 03:45:12 +0000 (20:45 -0700)]
Rollup merge of #102574 - aDotInTheVoid:const_collections_with_hasher, r=oli-obk,fee1-dead
Make Hash{Set,Map}::with_hasher unstably const
Makes [`HashMap::with_hasher`](https://doc.rust-lang.org/stable/std/collections/hash_map/struct.HashMap.html#method.with_hasher) and [`HashSet::with_hasher`](https://doc.rust-lang.org/stable/std/collections/hash_set/struct.HashSet.html#method.with_hasher) `const`.
- Provide a better error message when mixing dep: with / (rust-lang/cargo#11172)
- Remove lingering unstable flag `-Zfeatures` (rust-lang/cargo#11168)
- Tweak wording (rust-lang/cargo#11164)
- Expose libgit2-sys/vendored feature as vendored-libgit2 (rust-lang/cargo#11162)
- refactor(cli): Upgrade to clap v4 (rust-lang/cargo#11159)
- Expose guide to adding a new edition as rustdoc (rust-lang/cargo#11157)
- Remove `multitarget` from -Zhelp (rust-lang/cargo#11158)
- Remove outdated comments (rust-lang/cargo#11155)
- Provide a better error message when mixing dep: with / (rust-lang/cargo#11172)
- Remove lingering unstable flag `-Zfeatures` (rust-lang/cargo#11168)
- Tweak wording (rust-lang/cargo#11164)
- Expose libgit2-sys/vendored feature as vendored-libgit2 (rust-lang/cargo#11162)
- refactor(cli): Upgrade to clap v4 (rust-lang/cargo#11159)
- Expose guide to adding a new edition as rustdoc (rust-lang/cargo#11157)
- Remove `multitarget` from -Zhelp (rust-lang/cargo#11158)
- Remove outdated comments (rust-lang/cargo#11155)
bors [Tue, 4 Oct 2022 16:29:26 +0000 (16:29 +0000)]
Auto merge of #102666 - matthiaskrgr:rollup-tuge18t, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #102241 (Package `rust-docs-json` into nightly components (take 3))
- #102488 (Check generic argument compatibility when projecting assoc ty)
- #102647 (Only allow ~const bounds for traits with #[const_trait])
- #102648 (Add test for #102605)
- #102651 (It's not about types or consts, but the lack of regions)
- #102653 (resolve instance: missing value to `delay_span_bug`)
Matthias Krüger [Tue, 4 Oct 2022 16:26:41 +0000 (18:26 +0200)]
Rollup merge of #102651 - oli-obk:non_region_things, r=lcnr
It's not about types or consts, but the lack of regions
pulled out of https://github.com/rust-lang/rust/pull/101900 which adds a fourth kind of non-lifetime generic parameter, and the naming of these methods would get ridiculous.
Matthias Krüger [Tue, 4 Oct 2022 16:26:38 +0000 (18:26 +0200)]
Rollup merge of #102241 - jyn514:manifest-json-docs, r=Mark-Simulacrum
Package `rust-docs-json` into nightly components (take 3)
`dist` creates a `rust-docs-json.tar.xz` tarfile. But build-manifest expected it to be named `rust-docs-json-preview.tar.xz`. Change build-manifest to allow the name without the `-preview` suffix.
I haven't actually tested this :( build-manifest is a pain to run locally.
bors [Tue, 4 Oct 2022 13:04:57 +0000 (13:04 +0000)]
Auto merge of #102652 - Dylan-DPC:rollup-6ff8ct8, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #101189 (Implement `Ready::into_inner()`)
- #101642 (Fix in-place collection leak when remaining element destructor panic)
- #102489 (Normalize substs before resolving instance in `NoopMethodCall` lint)
- #102559 (Don't ICE when trying to copy unsized value in const prop)
- #102568 (Lint against nested opaque types that don't satisfy associated type bounds)
- #102633 (Fix rustdoc ICE in invalid_rust_codeblocks lint)
Alex Gaynor [Thu, 30 Jun 2022 19:01:38 +0000 (15:01 -0400)]
resolve error when attempting to link a universal library on macOS
Previously attempting to link universal libraries into libraries (but not binaries) would produce an error that "File too small to be an archive". This works around this by using `object` to extract a library for the target platform when passed a univeral library.
Dylan DPC [Tue, 4 Oct 2022 10:41:02 +0000 (16:11 +0530)]
Rollup merge of #102559 - compiler-errors:issue-102553, r=oli-obk
Don't ICE when trying to copy unsized value in const prop
When we have a trivially false where-clause predicate like `Self: Sized` where `Self = dyn Trait`, we sometimes don't throw an error during typeck for an illegal operation such as copying an unsized type.
This, unfortunately, cannot be made into an error (at least not without some migration -- see #95611 for example), but we should at least not ICE, since this function will never actually be reachable from main, for example.
r? `@RalfJung` since I think you added these assertions? but feel free to reassign.
Dylan DPC [Tue, 4 Oct 2022 10:41:01 +0000 (16:11 +0530)]
Rollup merge of #101642 - SkiFire13:fix-inplace-collection-leak, r=the8472
Fix in-place collection leak when remaining element destructor panic
Fixes #101628
cc `@the8472`
I went for the drop guard route, placing it immediately before the `forget_allocation_drop_remaining` call and after the comment, as to signal they are closely related.
I also updated the test to check for the leak, though the only change really needed was removing the leak clean up for miri since now that's no longer leaked.
Dylan DPC [Tue, 4 Oct 2022 10:41:00 +0000 (16:11 +0530)]
Rollup merge of #101189 - daxpedda:ready-into-inner, r=joshtriplett
Implement `Ready::into_inner()`
Tracking issue: #101196.
This implements a method to unwrap the value inside a `Ready` outside an async context.
See https://docs.rs/futures/0.3.24/futures/future/struct.Ready.html#method.into_inner for previous work.
This was discussed in [Zulip beforehand](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/.60Ready.3A.3Ainto_inner.28.29.60):
> An example I'm hitting right now:
I have a cross-platform library that provides a functions that returns a `Future`. The only reason why it returns a `Future` is because the WASM platform requires it, but the native doesn't, to make a cross-platform API that is equal for all I just return a `Ready` on the native targets.
>
> Now I would like to expose native-only functions that aren't async, that users can use to avoid having to deal with async when they are targeting native. With `into_inner` that's easily solvable now.
>
> I want to point out that some internal restructuring could be used to solve that problem too, but in this case it's not that simple, the library uses internal traits that return the `Future` already and playing around with that would introduce unnecessary `cfg` in a lot more places. So it is really only a quality-of-life feature.
bors [Tue, 4 Oct 2022 06:47:21 +0000 (06:47 +0000)]
Auto merge of #102644 - matthiaskrgr:rollup-rg0sw41, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #102441 (Suggest unwrap_or_else when a closure is given)
- #102547 (Migrate CSS theme for search results)
- #102567 (Delay evaluating lint primary message until after it would be suppressed)
- #102624 (rustdoc: remove font family CSS on `.rustdoc-toggle summary::before`)
- #102628 (Change the parameter name of From::from to `value`)
- #102637 (Ignore fuchsia on two compiler tests)
- #102639 (Improve spans when splitting multi-char operator tokens for proc macros.)
Failed merges:
- #102496 (Suggest `.into()` when all other coercion suggestions fail)
Matthias Krüger [Tue, 4 Oct 2022 04:14:13 +0000 (06:14 +0200)]
Rollup merge of #102639 - nnethercote:improve-spans-splitting, r=Aaron1011
Improve spans when splitting multi-char operator tokens for proc macros.
When a two-char (or three-char) operator token is split into single-char operator tokens before being passed to a proc macro, the single-char tokens are given the original span of length two (or three). This PR gives them more accurate spans.
Matthias Krüger [Tue, 4 Oct 2022 04:14:12 +0000 (06:14 +0200)]
Rollup merge of #102628 - H4x5:master, r=scottmcm
Change the parameter name of From::from to `value`
The `From` trait is currently defined as:
```rust
pub trait From<T>: Sized {
fn from(_: T) -> Self;
}
```
The name of the argument is `_`. I am proposing to change it to `value`, ie.
```rust
pub trait From<T>: Sized {
fn from(value: T) -> Self;
}
```
This would be more consistent with the `TryFrom`, which looks like this:
```rust
pub trait TryFrom<T>: Sized {
type Error;
fn try_from(value: T) -> Result<Self, Self::Error>;
}
```
The reason for this proposal is twofold:
1. Consistency with the rest of the standard library. The `TryFrom` trait uses `value`, and no `From` implementation uses the default name (as it is quite useless).
2. When generating trait implementations with rust-analyzer/IntelliJ, the parameter name is copied, and it always has to be changed.
Optionally, another name like `x` could be used. I only propose `value` for consistency with `TryFrom`.
Changing parameter names is not a breaking change.
Note: this was originally posted as an internals thread [here](https://internals.rust-lang.org/t/change-the-argument-name-of-from-from/17480)
Matthias Krüger [Tue, 4 Oct 2022 04:14:11 +0000 (06:14 +0200)]
Rollup merge of #102624 - notriddle:notriddle/summary-before, r=GuillaumeGomez
rustdoc: remove font family CSS on `.rustdoc-toggle summary::before`
This rule became irrelevant since c58246efe47bea09d4f3e70f536e4c9bb7770749 made it so that the `summary::before` pseudo-element contains an SVG instead of text.
projects / rust.git / log