Allow unary operand types to be inferred later

[chenyukang]

Fixes #106138

Fix the inference issue by allowing Not and Neg operand types to remain unresolved until obligations and constraints can determine them.

closes #26830

[rustbot]

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 74 candidates
• Random selection from 20 candidates

[fee1-dead]

hard for me to know if this is the right thing to do, hmm..

r? types

[jackh726]

So, this is fairly minor, but is new behavior, so I wondering if a @rust-lang/types FCP might be appropriate.

View changes since this review

[jackh726]

This definitely needs a comment. But:

1. Can we just use resolve_vars_with_obligations here for all three?
2. If not, I think it makes sense to just move these into the match arms, rather than matching twice.

[chenyukang]

If we also use resolve_vars_with_obligations for Deref, this code will treat a later-inferred raw pointer as an overloaded Deref, for example this code was reporting a proper E0282:

fn make<T>() -> T {
    loop {}
}

fn main() {
    let pointer = make();
    //~^ ERROR type annotations needed
    let value = unsafe { *pointer };
    let _: *const u8 = pointer;
    let _: u8 = value;
}

error[E0282]: type annotations needed
  --> src/main.rs:9:9
   |
 9 |     let pointer = make();
   |         ^^^^^^^
10 |     //~^ ERROR type annotations needed
11 |     let value = unsafe { *pointer };
   |                          -------- type must be known at this point
   |
help: consider giving `pointer` an explicit type
   |
 9 |     let pointer: /* Type */ = make();
   |                ++++++++++++

For more information about this error, try `rustc --explain E0282`.

if we changed to use resolve_vars_with_obligations, the error changed to:

error[E0277]: the trait bound `*const u8: Deref` is not satisfied
  --> tests/ui/inference/unary-deref-late-raw-pointer-inference-issue-106138.rs:11:26
   |
11 |     let value = unsafe { *pointer };
   |                          ^^^^^^^^ the trait `Deref` is not implemented for `*const u8`

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0277`.

I'm not sure whether there is other cases, we'd better keep structurally_resolve_type for Deref, and I added this test code as a unit test.

[dianne]

This should also close #26830, I think?

Also, for what it's worth, this would slightly expand the surface area of #114380 (also reported as #151202). Currently, the following fails to type-check:

fn main() {
    let input = Default::default();
    let output = !{ input };
    let _: u8 = output;
    println!("{}", std::any::type_name_of_val(&input));
}

Under this PR, it would compile successfully and print u8. let output = !{ input }; erroneously coerces input to the expected type of the negation as a whole, unifying its type with that of output (which is now allowed to be inferred later).

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[chenyukang]

This should also close #26830, I think?

Also, for what it's worth, this would slightly expand the surface area of #114380 (also reported as #151202). Currently, the following fails to type-check:

fn main() {
    let input = Default::default();
    let output = !{ input };
    let _: u8 = output;
    println!("{}", std::any::type_name_of_val(&input));
}

Under this PR, it would compile successfully and print u8. let output = !{ input }; erroneously coerces input to the expected type of the negation as a whole, unifying its type with that of output (which is now allowed to be inferred later).

I added a test in this PR for #26830

[chenyukang]

@rustbot ready

[jackh726]

@rfcbot merge types

Minor change here. This Not and Neg unary operators use resolve_vars_with_obligations instead of structurally_resolve_type, which lets us infer the output from later information.

[rust-rfcbot]

@jackh726 has proposed to merge this. The next step is review by the rest of the tagged team members:

• @BoxyUwU
• @jackh726
• @lcnr
• @oli-obk
• @spastorino

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[lcnr]

This is okay because we don't do auto-derefs/coercions here, we don't do this for indexing or field projections as x[7] can be called on x: &&&&&&[u32].

I do feel the argument that |index, y: &[u32]| !y[index] should compile to be quite strong and don't feel like ! of x: &u32 should necessarily automatically deref x 🤔

At this point this is a lang design tradeoff, cc @rust-lang/lang whether you want to be involved here. An alternative would be to allow ! and - to apply auto-derefs, we cannot support both "apply the operator to inference variables" and "apply auto-deref", as doing so must happen eagerly.

[BoxyUwU]

this seems related to #151539

would like for whoever reviews this PR to also review that PR potentially 🤔

[rust-bors]

☔ The latest upstream changes (presumably #162229) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[dianne]

this seems related to #151539

in relation to #151539, I had been considering taking advantage of how we don't allow unary operand types to be inferred later in that PR, but I'm not so sure about that approach now. as far as I was able to tell, linting on code that would break from fixing that inference bug (for an FCW or edition migration) either requires a pretty involved change or something pretty hacky. as I recall, for the hacky approach, disallowing unary operand types from being inferred later would make it easier to only lint on code that would fail to compile under the bugfix (...hopefully. I haven't tried going back to it and making it account for some missing cases). but ideally it'd be nice not to do the hacky thing at all