never_patterns: Count ! bindings as diverging

[Nadrieril]

A binding that is a never pattern is not reachable, hence counts as diverging code. This allows in particular fn foo(!: Void) -> SomeType {} to typecheck.

r? @compiler-errors

[compiler-errors]

Ok, so I understand what this is doing, but I'm not certain if I understand why it's doing this. Is this to make some test pass?

[Nadrieril]

The old_diverges bit you mean? That's because if an expression diverges then it typechecks as !. So before we check a new expression we hide the previous state of diverges. Else in the following 1 would be given type !.

panic!();
let x = 1;

[compiler-errors]

No, why you added this is_whole_body thing.

[Nadrieril]

Ah. Well the presence of ! in the arguments should affect the type of the function body, but not the type of any other expression in the function. So I only look at function_diverges_because_of_empty_arguments if expr is the function body

[Nadrieril]

The obvious thing to do would have been to set fcx.diverges directly while checking the function arguments, but that resulted in:

fn never_arg(!: Void) -> u32 {}
                             ^^ unreachable code

as well as a type error because the mechanism I explained above ensures that the type of the {} was not affected by previous diverges so the body is typechecked as () x)

[Nadrieril]

I guess I could use diverges directly instead of adding function_diverges_because_of_empty_arguments 🤔 . But I still need is_whole_body

[compiler-errors]

I understand why this is implemented the way it is, though I'm still chewing on whether there's a better approach here. My main concern is the non-locality -- it relies on the fact that when type checking the top expression of the body, we'll always flow through check_expr_with_expectation_and_args first. While I believe typeck will remain in that way, it seems somewhat easy for a refactoring of control flow to make this no longer true always.

Ideally, we'd treat the initial check_expr call for the top expr of a body in a privileged way, and do this logic there, but currently all of that is tangled into the coercion code that we use to check the body as if it were an implicit return value. Sigh.

[compiler-errors]

As an aside, could you please double check that this still behaves the right way for async fn?

async fn(!: Void) { body... }

implicitly desugars to:

fn(arg1: Void) -> ... {
  async { 
    let ! = arg1;
    body...
  }
}

so it should behave correctly afaict, but I think we should have tests for that.

[Nadrieril]

Yeah, I'm not a fan of the non-locality and the mutability of my implementation but I felt way out of my depth to refactor anything.

Good catch on the async fn, it in fact does not work. I'm surprised because I looked at all the call sites of check_pat_top and they all do something with never patterns except expression-lets

[Nadrieril]

Weird, it does desugar to what you said, but doesn't seem to detect the divergence

[compiler-errors]

r=me after fixing up the async test commit

[compiler-errors]

@bors r+

[bors]

📌 Commit 3ff1024 has been approved by compiler-errors

It is now in the queue for this repository.

[Nadrieril]

Ty!