```rust
fn main() {
let v = Vec::new();
v.push(0);
v.push(0);
v.push("");
}
```
now produces
```
error[E0308]: mismatched types
--> $DIR/point-at-inference-3.rs:6:12
|
LL | v.push(0);
| - this is of type `{integer}`, which makes `v` to be inferred as `Vec<{integer}>`
...
LL | v.push("");
| ---- ^^ expected integer, found `&str`
| |
| arguments to this function are incorrect
|
note: associated function defined here
--> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL
```
- Only point at a the single expression where the found type was first
inferred.
- Find method call argument that might have caused the found type to be
inferred.
- Provide structured suggestion.
- Apply some review comments.
- Tweak wording.
Rollup of 6 pull requests
Successful merges:
- #105846 (Account for return-position `impl Trait` in trait in `opt_suggest_box_span`)
- #106385 (Split `-Zchalk` flag into `-Ztrait-solver=(classic|chalk|next)` flag)
- #106403 (Rename `hir::Map::{get_,find_}parent_node` to `hir::Map::{,opt_}parent_id`, and add `hir::Map::{get,find}_parent`)
- #106462 (rustdoc: remove unnecessary wrapper around sidebar and mobile logos)
- #106464 (Update Fuchsia walkthrough with new configs)
- #106478 (Tweak wording of fn call with wrong number of args)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Split `-Zchalk` flag into `-Ztrait-solver=(classic|chalk|next)` flag
We'll eventually need a way to select more than chalk + not-chalk.
Does this need an MCP since it's touching a `-Z` flag? Or perhaps I should preserve `-Zchalk` for the time being... maybe I could make it a warning to use that flag? cc ``@rust-lang/types``
r? types
Account for return-position `impl Trait` in trait in `opt_suggest_box_span`
RPITITs are the only types where their opaque bounds might normalize to some other self type than the opaque type itself. To avoid needing to do normalization, let's just match on either alias kind.
Ideally, we'd just get rid of `opt_suggest_box_span`. It's kind of a wart on type-checking `if`/`match`. I've recently refactored this expression for being confusing/wrong, but moving it into the error path is pretty hard.
Fixes#105838
Don't deduce a signature that makes a closure cyclic
Sometimes when elaborating supertrait bounds for closure signature inference, we end up deducing a closure signature that is cyclical because either a parameter or the return type references a projection mentioning `Self` that also has escaping bound vars, which means that it's not eagerly replaced with an inference variable.
Interestingly, this is not *just* related to my PR that elaborates supertrait bounds for closure signature deduction. The committed test `supertrait-hint-cycle-3.rs` shows **stable** code that is fixed by this PR:
```rust
trait Foo<'a> {
type Input;
}
impl<F: Fn(u32)> Foo<'_> for F {
type Input = u32;
}
fn needs_super<F: for<'a> Fn(<F as Foo<'a>>::Input) + for<'a> Foo<'a>>(_: F) {}
fn main() {
needs_super(|_: u32| {});
}
```
Fixes#105401Fixes#105396
r? types
Rollup of 7 pull requests
Successful merges:
- #106200 (Suggest `impl Fn*` and `impl Future` in `-> _` return suggestions)
- #106274 (Add JSON output to -Zdump-mono-stats)
- #106292 (Add codegen test for `Box::new(uninit)` of big arrays)
- #106327 (Add tidy check for dbg)
- #106361 (Note maximum integer literal for `IntLiteralTooLarge`)
- #106396 (Allow passing a specific date to `bump-stage0`)
- #106436 (Enable doctests for rustc_query_impl)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Suggest `impl Fn*` and `impl Future` in `-> _` return suggestions
Follow-up to #106172, only the last commit is relevant. Can rebase once that PR is landed for easier review.
Suggests `impl Future` and `impl Fn{,Mut,Once}` in `-> _` return suggestions.
r? `@estebank`
layout_of: `T: Thin` implies `sizeof(&T) == sizeof(usize)`
Use the `<T as Pointee>::Metadata` associated type to calculate the layout of a pointee's metadata, instead of hard-coding rules about certain types.
Maybe this approach is overkill -- we could instead hard-code this approach as a fallback, with the matching on `Slice`/`Dynamic`/etc. happening first
Fixes this issue here https://github.com/rust-lang/rust/pull/104338#issuecomment-1312595844 .. But is also useful with transmutes, for example, given the UI test I added below.
Test the borrowck behavior of if-let guards
Add some tests to make sure that if-let guards behave the same as if guards with respect to borrow-checking. Most of them are a naive adaptation, replacing an `if` guard with `if let Some(())`.
This includes regression tests for notable issues that arose for if guards (#24535, #27282, #29723, #31287) as suggested in https://github.com/rust-lang/rust/issues/51114#issuecomment-900470419.
cc `@pnkfelix` are there any other tests that you would want to see?
cc tracking issue #51114
HIR debug output is currently very verbose, especially when used with
the alternate (`#`) flag. This commit reduces the amount of noisy
newlines by forcing a few small key types to stay on one line, which
makes the output easier to read and scroll by.
```
$ rustc +after hello_world.rs -Zunpretty=hir-tree | wc -l
582
$ rustc +before hello_world.rs -Zunpretty=hir-tree | wc -l
932
```
refactor: merge error code `E0465` into `E0464`
`E0465` is an undocumented and untested error code that is functionally identical to `E0464`. This PR merges `E0465` into `E0464`, thus documenting and testing another error code (#61137).
r? `@GuillaumeGomez` (not sure if you want to review this but it's relevant to my other PRs that you have reviewed)
Revert "Implement allow-by-default `multiple_supertrait_upcastable` lint"
This is a clean revert of #105484.
I confirmed that reverting that PR fixes the regression reported in #106247. ~~I can't say I understand what this code is doing, but maybe it can be re-landed with a different implementation.~~ **Edit:** https://github.com/rust-lang/rust/issues/106247#issuecomment-1367174384 has an explanation of why #105484 ends up surfacing spurious `where_clause_object_safety` errors. The implementation of `where_clause_object_safety` assumes we only check whether a trait is object safe when somebody actually uses that trait with `dyn`. However the implementation of `multiple_supertrait_upcastable` added in the problematic PR involves checking *every* trait for whether it is object-safe.
FYI `@nbdd0121` `@compiler-errors`
The test was minified from the published `msf-ice:0.2.1` crate which failed in a crater run.
A faulty compiler was triggering a `higher-ranked lifetime error`:
> could not prove `[async block@...]: Send`
Rollup of 9 pull requests
Successful merges:
- #104531 (Provide a better error and a suggestion for `Fn` traits with lifetime params)
- #105899 (`./x doc library --open` opens `std`)
- #106190 (Account for multiple multiline spans with empty padding)
- #106202 (Trim more paths in obligation types)
- #106234 (rustdoc: simplify settings, help, and copy button CSS by not reusing)
- #106236 (docs/test: add docs and a UI test for `E0514` and `E0519`)
- #106259 (Update Clippy)
- #106260 (Fix index out of bounds issues in rustdoc)
- #106263 (Formatter should not try to format non-Rust files)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
docs/test: add docs and a UI test for `E0514` and `E0519`
No UI test on `E0514`, it would need to compile with a different `rustc` version.
r? `@GuillaumeGomez`
