This enables us to stop treating the return type as a Pattern (which is really isn't), treat return types more consistently with other static types in the typechecker, and drop ReturnTypeContext.
Additional changes:
- Merge TypeCheckFunDef with TypeOfFunDef.
- Handle implicit conversions in `return` statements.
- Require function type literals to have an explicit `->`.
- Move consistency check for omitted returns from TypeChecker to ResolveControlFlow.
The `__Fn` naming is intended to mirror things like `__Continuation`.
The reason for this path is because it's not clear this is the form we'll want, and I think experimental naming will help reflect that.
Rationale: Based on the status of #478 and #505, Carbon won't have this feature for a while, and it will be simpler not to support it on spec in the meantime.
I should emphasize that I am **completely cheating** here. This PR does not add support for actually _performing_ implicit conversions at run time, because the AST doesn't yet contain the necessary type information. At run time, code like `var p: Point = {.x = 1, .y = 2};` directly initializes the name `p` with the _struct_ value `{.x = 1, .y = 2}`; no object of type `Point` is actually created. I'm only getting away with this because we don't yet have any tests that can tell the difference.
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
This implements #826, I think covering everything important there.
Regarding ReturnTypeContext, I broke that out because it started feeling like a significant number of args to be passing around, and I think this makes the association inside type checking clearer.
Co-authored-by: Geoff Romer <gromer@google.com>
There's a small update to update_checks.py to handle the recursive directories. Also, I'm only using one level of nesting in this PR but really no reason we can't do more. I'm just not sure what clustering is best right now.
As a pattern, I'm trying to name all failing tests `fail_*.carbon`.
Geoff Romer
Jon Meow