let-else: test else block with non-never uninhabited type
let else currently does not allow uninhabited types for the `else` block that aren't `!`. One can maybe think about relaxing this in the future, but if it is done, it should be an explicit choice and not an unexpected side effect of e.g. a refactor. Thus, I'm extending a test that will fail if the behaviour changes.
Disable compressed debug sections on i586-gnu
Compressed debug is enabled by default for gas (assembly) on Linux/x86
targets, and we started building our own in #102530, but that made our
`compiler_builtins` incompatible with binutils < 2.32. Add an explicit
option to disable that in our crosstool-ng config. Fixes#102703.
rustdoc: remove unused CSS `.docblock a:not(.srclink)`
This selector was added in c7312fbae4, because the list of impl items could be nested below `docblock`.
c7312fbae4/src/librustdoc/html/render.rs (L3841-L3845)
Now that rustdoc toggles have been switched to `<details>`, there shouldn't be any need to put things inside docblock containers just to give them disclosure toggles.
rustdoc: remove unused CSS `.content .item-list`
When these rules were added in 4fd061c426 (yeah, that's the very first commit of rustdoc_ng), `.item-list` was a `<ul>`, and this would override the default style for that tag.
In c1b1d6804b, it was changed to use a `<div>` tag, so these rules are both no-ops.
Compressed debug is enabled by default for gas (assembly) on Linux/x86
targets, and we started building our own in #102530, but that made our
`compiler_builtins` incompatible with binutils < 2.32. Add an explicit
option to disable that in our crosstool-ng config. Fixes#102703.
This selector was added in c7312fbae4,
because the list of impl items could be nested below `docblock`.
c7312fbae4/src/librustdoc/html/render.rs (L3841-L3845)
Now that rustdoc toggles have been switched to `<details>`, there shouldn't
be any need to put things inside docblock containers just to give them
disclosure toggles.
When these rules were added in 4fd061c426
(yeah, that's the very first commit of rustdoc_ng), `.item-list` was a
`<ul>`, and this would override the default style for that tag.
In c1b1d6804b, it was changed to use a
`<div>` tag, so these rules are both no-ops.
lint::unsafe_removed_from_name: fix false positive result when allowed
changelog: [`unsafe_removed_from_name`] Fix allowing on imports produces a false positive on `useless_attribute`.
Fixes: #9197
Signed-off-by: Andy-Python-Programmer <andypythonappdeveloper@gmail.com>
Remove `-Ztime`
Because it has a lot of overlap with `-Ztime-passes` but is generally less useful. Plus some related cleanups.
Best reviewed one commit at a time.
r? `@davidtwco`
Fix overconstrained Send impls in btree internals
Fixes https://github.com/dtolnay/async-trait/issues/215.
Minimal repro:
```rust
use std::collections::btree_map::Iter;
fn require_send<T: Send>(_: T) {}
fn main() {
require_send(async {
let _iter = None::<Iter<(), &()>>;
async {}.await;
});
}
```
```console
error: higher-ranked lifetime error
--> src/main.rs:6:5
|
6 | / require_send(async {
7 | | let _iter = None::<Iter<(), &()>>;
8 | | async {}.await;
9 | | });
| |______^
|
= note: could not prove `impl Future<Output = ()>: Send`
```
Not-quite-so-minimal repro:
```rust
use std::collections::BTreeMap;
use std::future::Future;
fn spawn<T: Future + Send>(_: T) {}
async fn f() {
let map = BTreeMap::<u32, Box<dyn Send + Sync>>::new();
for _ in &map {
async {}.await;
}
}
fn main() {
spawn(f());
}
```
```console
error: higher-ranked lifetime error
--> src/main.rs:14:5
|
14 | spawn(f());
| ^^^^^^^^^^
|
= note: could not prove `impl Future<Output = ()>: Send`
```
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`
```
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))
r? `@lcnr`
Add a temporary workaround for multiline formart arg inlining
per suggestion in
https://github.com/rust-lang/rust/pull/102729#discussion_r988990080
workaround for an internal crash when handling multi-line format argument inlining.
changelog: none
(no point for changelog because it is still a new lint being introduced)
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.
`@rustbot` label T-rustdoc A-cross-crate-reexports
r? `@GuillaumeGomez`
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)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
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 {
+ | +
```
And this fixes a part of #97469
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.
r? diagnostics
Fixes#102518
`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.
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.
r? `@oli-obk`
