Projection types in user annotations may contain inference variables.
This makes the normalization depend on the unification with the actual
type and thus requires a separate TypeOp to track the obligations.
Otherwise simply calling `TypeChecker::normalize` would ICE with
"unexpected ambiguity"
We delay projection normalization to further stages in order to
register user type annotations before normalization in HIR typeck.
There are two consumers of astconv: ItemCtxt and FnCtxt.
The former already expects unnormalized types from astconv, see its
AstConv trait impl.
The latter needs `RawTy` for a cleaner interface.
Unfortunately astconv still needs the normalization machinery in
order to resolve enum variants that have projections in the self type,
e.g. `<<T as Trait>::Assoc>::StructVariant {}`.
This is why `AstConv::normalize_ty_2` is necessary.
Suggest adding named lifetime when the return contains value borrowed from more than one lifetimes of function inputs
fix for #105227.
The problem: The suggestion of adding an explicit `'_` lifetime bound is **incorrect** when the function's return type contains a value which could be borrowed from more than one lifetimes of the function's inputs. Instead, a named lifetime parameter can be introduced in such a case.
The solution: Checking the number of elided lifetimes in the function signature. If more than one lifetimes found in the function inputs when the suggestion of adding explicit `'_` lifetime, change it to using named lifetime parameter `'a` instead.
fix [type error] for error E0029 and E0277
check explicitly for the type references error
if ty.references_error() is true change the error to be err.delay_as_bug() and prevent the error E0029 and E0277 from emitting out this fix#105946
check explicitly for the type references error
if ty.references_error() is true change the error to be err.delay_as_bug()
and prevent the error E0029 and E0277 from emitting out
this fix#105946
```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
```
