Typecheck refactor for !

[canndrew]

Ping @nikomatsakis @eddyb. This is the PR for the typeck refactor for !. Is this what you guys had in mind? Is there anything else that needs doing on it?

[rust-highfive]

r? @arielb1

(rust_highfive has picked a reviewer for you, use r? to override)

[eddyb]

Why this change? expr_ty is a better name for such a variable.

[canndrew]

Because having a method named expr_ty and a variable named expr_ty is confusing.

[eddyb]

I find _t worse. Besides, why do we still need the expr_ty method?

[canndrew]

expr_ty is still used in a few places. I can keep going trying to remove it entirely if you like. Otherwise I can rename the variable ty.

[eddyb]

Either sound good, thanks!

[arielb1]

I would move the match in check_expr_with_expectation_and_lvalue_pref to its own function, to prevent confusion if someone introduces a return there.

[eddyb]

check_block_with_expected should return the type.

[canndrew]

@eddyb is this PR good to go? I can do the same thing with patterns (factoring out write_ty) if you'd like.

[eddyb]

@canndrew Yeah, doing that would be great. Are there many expr_ty calls left, btw?

[bors]

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

[canndrew]

I've done the factoring-out for patterns. There's still some uses of expr_ty left though most of them look like they'll be non-trivial to get rid of (the ones in coercion.rs and confirm.rs).

[eddyb]

@canndrew Can't both of those takes the types in? Although not confirm.rs if it's a late adjustment.
That is, I'd like to remove uses of expr_ty that are done near the expression being type-checked, and keep only those that are deferred, possibly manually getting the node type if there's only 2-3 of them.

[canndrew]

I've made the coercions code take the types as arguments.

The code in confirm.rs walks over a big expression tree reading the types using expr_ty. So there's no way to pass the types in there. I could replace the expr_tys with node_tys but it means that code will no longer be able to see the AdjustNeverToAny coercion (does that matter?).

[eddyb]

This shouldn't be needed though. The design was such that no extra bookkeeping was needed.

[canndrew]

Any idea what these LLVM linker errors are about?

[bors]

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

[canndrew]

@eddyb I rebased this and now it's passing. Is it good to merge?

[eddyb]

@bors r+ Thanks!

[bors]

📌 Commit c9a340e has been approved by eddyb

[bors]

⌛ Testing commit c9a340e with merge 58dc448...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-cross-freebsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-rustbuild
Approved by: eddyb
Pushing 58dc448 to master...