Use FileCheck's `[[@LINE+n]]` mechanism to refer to the next line.
This is made awkward by a couple of things:
* We want to keep the `CHECK` lines in the original order.
* Errors are sometimes more than one line long.
The approach we use is to interleave the original lines and the check lines, putting each check line as early as possible subject to two rules:
1) Check lines never precede the 'AUTOUPDATE' line
2) Except when required by rule (1), a check line that refers to a source line by line number is never placed earlier than a source line that precedes that source line.
The actual `[[@LINE+n]]` annotations are created in a second pass after we've interleaved the lines so that we can work out the correct offsets.
Co-authored-by: Jon Meow <jperkins@google.com>
* check that the return type is a type, add more implicit conversions
* update IsConcreteType for generic classes, add IsType predicate
* delete a comment
* trivial change
* move Witness wrt IsConcreteType and IsType
* added comments to tests
* update error line numbers
Breaks `--trace` into two flags:
- `--parser_debug`, which sets the parser debug level (which I haven't dug into piping with `--trace`, but seemed likely to be troublesome)
- `--trace_file`, which now the type checker and interpreter will use for trace information (note compile errors should use a different channel)
Most of the file edits are just mechanical testdata flag updates: `sed -i 's/--trace/--parser_debug --trace_file=-/' testdata/**/*.carbon`
To explain the output paths:
- parse/compile errors: stderr
- print() calls: stdout
- parser tracing: `--parser_debug` option, stdout (formerly stdout if `--trace`)
- type check/compile tracing: `--trace_file=<file>`, giving `-` uses stdout (formerly stdout if `--trace`)
- return code of executed Carbon code: `--trace_file` if set, stdout if not (formerly stdout always)
As a byproduct, replace NamedEntity with a type-erasing wrapper NamedEntityView, eliminate virtual inheritance from the AST, and eliminate interfaces from gen_rtti.
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`.