Support struct implicit conversions in type-checking (#870)

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 commit is contained in:
Geoff Romer
2021-10-12 10:27:20 -07:00
committed by GitHub
co-authored by Jon Meow
parent a99d882223
commit bc5a42211b
14 changed files with 226 additions and 60 deletions
@@ -2,16 +2,16 @@
// Exceptions. See /LICENSE for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
// RUN: not executable_semantics %s 2>&1 | \
// RUN: executable_semantics %s 2>&1 | \
// RUN: FileCheck --match-full-lines --allow-unused-prefixes=false %s
// RUN: not executable_semantics --trace %s 2>&1 | \
// RUN: executable_semantics --trace %s 2>&1 | \
// RUN: FileCheck --match-full-lines --allow-unused-prefixes %s
// AUTOUPDATE: executable_semantics %s
// CHECK: COMPILATION ERROR: {{.*}}/executable_semantics/testdata/struct/fail_name_order.carbon:17: Type pattern '{.x: i32, .y: i32}' does not match actual type '{.y: i32, .x: i32}'
// CHECK: result: 0
package ExecutableSemanticsTest api;
// Test the that field order matters for structs.
// Test the that field order doesn't matter for structs.
fn main() -> i32 {
var t: {.x: i32, .y: i32} = {.y = 2, .x = 3};