Closed Hugobros3 closed 3 years ago
For reference, from our discussion:
StructDecl
should hold const EnumDecl* parent
, and provide size_t enum_variant_index
as a function, not a member,RecordPtrn::needs_ctor_matching
should be a function as well (it's in fact equal to match_app<EnumType>(record_ptrn->type).second
),auto [type_app, struct_type] = match_app<StructType>(path.type);
auto [type_app2, enum_type] = match_app<EnumType>(path.type);
by
auto [_, struct_type] = match_app<StructType>(path.type);
auto [__, enum_type] = match_app<EnumType>(path.type);
auto type_app = path.type->isa<TypeApp>();
make coverage
enum E { A(i32) }
fn test() { let f = E::A; f(1) }
I still have to look into coverage, and fix the docs
It occurred to me I can simplify the codegen for constructing tuple-like enum variants, since capturing those constructors is no longer legal, we do not have to emit a continuation for those in Path::emit
and can directly build the thorin variant in CallExpr::emit
, just like I do for record-like enum variant initialization in RecordExpr
: https://github.com/AnyDSL/artic/blob/tuple-like-struct/src/emit.cpp#L912
This PR adds support for "tuple-like" structures and "struct-like" enum options, as described in https://github.com/AnyDSL/artic/projects/7. This also includes "empty" tuple-like structs, which do not have either parentheses or brackets following them.
The syntax for constructing and matching on structs or enum options has to match the syntax used when declaring them: This means you cannot initialize something like
struct S { x: f32, y: f32, z: f32 }
withS(0.0, 0.0, 0.0
). Likewise you cannot access the fields of a tuple-like struct by projection (ies.0
), instead you have to match and deconstruct them like tuples instead. It is not possible to match/deconstruct an empty tuple-like struct, and such an action would be pointless anyway since an empty struct carries no information.In effect those changes make the different data constructor syntaxes (nothing, parentheses with ordered fields and curly brackets with named fields) orthogonal to structs and enums types. We now have "record" and "call" syntax for (de)constructing data, so therefore in the source this is reflected by renaming the AST nodes
StructExpr
/StructPtrn
toRecordExpr
/RecordPtrn
andEnumPtrn
toCallPtrn
(matching the existingCallExpr
).