Enum Compilation #79
Comments
philberty
modified the milestones:
Data Structures 1 - Core,
Data Structures 2 - Generics
|
I believe there is more work here to turn this into GIMPLE than meets the eye so it would be best to tackle this in the next data structure milestone |
philberty
modified the milestones:
Data Structures 2 - Generics,
Data Structures 3 - Traits
bors bot
added a commit
that referenced
this issue
Jun 24, 2021
522: Handle empty/unit tuple enum variants in the parser. r=philberty a=philberty A tuple enum variant can be empty, in which case it is a unit enum variant. Handle this in Parser<ManagedTokenSource>::parse_enum_item by creating a empty tuple_field vector instead of calling parse_tuple_fields. Add a testcase to show empty tuple enum variant types are now accepted. But note some part of the test is commented out because using the enum type isn't actually possible right now. Addresses #79 Co-authored-by: Mark Wielaard <mark@klomp.org>
philberty
added a commit
that referenced
this issue
Oct 30, 2021
Algebraic data types represent Structs, Tuple Structs, unit structs and enums in rust. The key difference here is that each of these are an ADT with a single variant and enums are an ADT with multiple variants. It adds indirection to where the fields of an ADT are managed. Co-authored-by: Mark Wielaard <mark@klomp.org> Addresses #79
philberty
pushed a commit
that referenced
this issue
Oct 30, 2021
This patch does the type resolution to actually create the types when we encounter enums within toplevel HIR::Items and HIR::Stmt conext's. We don't support actual creation of enums yet in this patch but this is an isolated building block. Co-authored-by: Philip Herron <philip.herron@embecosm.com> Addresses #79
philberty
added a commit
that referenced
this issue
Oct 30, 2021
Algebraic data types represent Structs, Tuple Structs, unit structs and enums in rust. The key difference here is that each of these are an ADT with a single variant and enums are an ADT with multiple variants. It adds indirection to where the fields of an ADT are managed. Co-authored-by: Mark Wielaard <mark@klomp.org> Addresses #79
philberty
pushed a commit
that referenced
this issue
Oct 30, 2021
This patch does the type resolution to actually create the types when we encounter enums within toplevel HIR::Items and HIR::Stmt conext's. We don't support actual creation of enums yet in this patch but this is an isolated building block. Co-authored-by: Philip Herron <philip.herron@embecosm.com> Addresses #79
philberty
added a commit
that referenced
this issue
Oct 30, 2021
When constructing enums we end up with a path like Enum::discriminant so we must lookup the variant to figure out how to construct the enum. Addresses #79
philberty
added a commit
that referenced
this issue
Nov 2, 2021
Algebraic data types represent Structs, Tuple Structs, unit structs and enums in rust. The key difference here is that each of these are an ADT with a single variant and enums are an ADT with multiple variants. It adds indirection to where the fields of an ADT are managed. Co-authored-by: Mark Wielaard <mark@klomp.org> Addresses #79
philberty
pushed a commit
that referenced
this issue
Nov 2, 2021
This patch does the type resolution to actually create the types when we encounter enums within toplevel HIR::Items and HIR::Stmt conext's. We don't support actual creation of enums yet in this patch but this is an isolated building block. Co-authored-by: Philip Herron <philip.herron@embecosm.com> Addresses #79
philberty
added a commit
that referenced
this issue
Nov 2, 2021
When constructing enums we end up with a path like Enum::discriminant so we must lookup the variant to figure out how to construct the enum. Addresses #79
philberty
added a commit
that referenced
this issue
Nov 2, 2021
Enums are ADT's with multiple variants where as structs are ADT's with a single variant, this changes the typechecking on construction of these to support enums. Addresses #79
bors bot
added a commit
that referenced
this issue
Nov 2, 2021
781: Add missing typechecking for enums r=philberty a=philberty This PR splits up the Algebraic data type into one which can support many variants which is what an enum is. It then changes the type checking for construction of ADT's to use the VariantDef structures as required. This does not fully implement but does allow us to have most of the type checking in place to start code-generation work. This combines work from Mark Wielaard (https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=enum-type) and Philip Addresses #79 Co-authored-by: Mark Wielaard <mark@klomp.org> Co-authored-by: Philip Herron <philip.herron@embecosm.com>
philberty
added a commit
that referenced
this issue
Dec 15, 2021
This adds a naieve first pass approach to enum type code generation. The
original idea was to use GCC's QUAL_UNION_TYPE but I have ran into issues
with the DECL_QUALIFIER as my understanding of how this works is incorrect.
This takes an enum such as:
```rust
enum AnEnum {
A,
B,
C (char),
D (x: i64, y: i64),
}
```
And turns this into one big union consisting of all fields as RECORD_TYPES.
```c
union AnEnum {
record A { RUST$ENUM$DISR };
record B { RUST$ENUM$DISR };
record C { RUST$ENUM$DISR, char };
record D { RUST$ENUM$DISR, i64, i64};
}
```
see: https://github.com/bminor/binutils-gdb/blob/527b8861cd472385fa9160a91dd6d65a25c41987/gdb/dwarf2/read.c#L9010-L9241
With the RUST$ENUM$DISR being the first field in all of the records this
means the alignment allows for indirect memory access of the struct to
use it as a qualifier field to figure out which variant is currently in
use. The data-less varients use their generated discriminat value during
type-checking the data variants use their HIR ID for their discriminant.
This will likely get redone to get improved GDB integration/updated to use
the QUAL_UNION_TYPE when we learn how to do this properly.
Fixes #79
bors bot
added a commit
that referenced
this issue
Dec 16, 2021
834: Add enum code generation r=philberty a=philberty
This adds a naieve first pass approach to enum type code generation. The
original idea was to use GCC's QUAL_UNION_TYPE but I have ran into issues
with the DECL_QUALIFIER as my understanding of how this works is incorrect.
This takes an enum such as:
```rust
enum AnEnum {
A,
B,
C (char),
D (x: i64, y: i64),
}
```
And turns this into one big union consisting of all fields as RECORD_TYPES.
```c
union AnEnum {
record A { RUST$ENUM$DISR };
record B { RUST$ENUM$DISR };
record C { RUST$ENUM$DISR, char };
record D { RUST$ENUM$DISR, i64, i64};
}
```
see: https://github.com/bminor/binutils-gdb/blob/527b8861cd472385fa9160a91dd6d65a25c41987/gdb/dwarf2/read.c#L9010-L9241
With the RUST$ENUM$DISR being the first field in all of the records this
means the alignment allows for indirect memory access of the struct to
use it as a qualifier field to figure out which variant is currently in
use. The data-less varients use their generated discriminat value during
type-checking the data variants use their HIR ID for their discriminant.
This will likely get redone to get improved GDB integration/updated to use
the QUAL_UNION_TYPE when we learn how to do this properly.
Fixes #79
Co-authored-by: Philip Herron <philip.herron@embecosm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should be able to compile the enum data structure this may avoid the match control flow for now.
Mark W has done most of the leg work for this one over on: https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=enum-type
The text was updated successfully, but these errors were encountered: