I'll suggest a more idiomatic layout:

pub const TypeInfo = union(TypeId) {
    Type: void,
    Void: void,
    Bool: void,
    NoReturn: void,
    Int: Int,
    Float: Float,
    Pointer: Pointer,
    Array: Array,
    Struct: Struct,
    FloatLiteral: void,
    IntLiteral: void,
    UndefinedLiteral: void,
    NullLiteral: void,
    Nullable: Nullable,
    ErrorUnion: ErrorUnion,
    ErrorSet: ErrorSet,
    Enum: Enum,
    Union: Union,
    Fn: Fn,
    Namespace: void,
    Block: void,
    BoundFn: BoundFn,
    ArgTuple: void,
    Opaque: void,
    Promise: Promise,

    pub const Int = struct {
        is_signed: bool,
        bits: u8,
    };

    pub const Float = struct {
        bits: u8,
    };

    pub const Pointer = struct {
        is_const: bool,
        is_volatile: bool,
        alignment: u32,
        child: &TypeInfo,
    };

    pub const Array = struct {
        len: usize,
        child: &TypeInfo,
    };

    pub const ContainerLayout = enum {
        Auto,
        Extern,
        Packed,
    };

    pub const StructField = struct {
        name: []const u8,
        offset: usize,
        type_info: TypeInfo,
    };

    pub const Struct = struct {
        layout: ContainerLayout,
        fields: []StructField,
    };

    pub const Nullable = struct {
        child: &TypeInfo,
    };

    pub const ErrorUnion = struct {
        error_set: ErrorSetInfo,
        payload: &TypeInfo,
    };

    pub const Error = struct {
        name: []const u8,
        value: usize,
    };

    pub const ErrorSet = struct {
        errors: []Error,
    };

    pub const EnumField = struct {
        name: []const u8,
        value: usize,
    };

    pub const Enum = struct {
        layout: ContainerLayout,
        tag_type: Int,
        fields: []EnumField,
    };

    pub const UnionField = struct {
        name: []const u8,
        enum_field: EnumField,
        type_info: TypeInfo,
    };

    pub const Union = struct {
        layout: ContainerLayout,
        tag_type: ?Enum,
        fields: []UnionField,
    };

    pub const CallingConvention = enum {
        Unspecified,
        C,
        Cold,
        Naked,
        Stdcall,
        Async,
    };

    pub const FnArg = struct {
        is_comptime: bool,
        name: []const u8,
        type_info: TypeInfo,
    };

    pub const Fn = struct {
        calling_convention: CallingConvention,
        is_generic: bool,
        is_varargs: bool,
        return_type: &TypeInfo,
        args: []FnArg,
    };

    pub const BoundFn = struct {
        bound_type: &TypeInfo,
        fn_info: Fn,
    };

    pub const Promise = struct {
        child: ?&TypeInfo,
    };

};

feel free to use a c++ multiline string here if it's easier (but do try to get the formatting right in the resulting builtin.zig file).

Also feel free to save this for last, it's just organization. To use this layout in ir.cpp you would take advantage of ir_build_field_ptr on the builtin that you get from get_builtin_value. You'd probably need to transform the builtin into a const ptr of it though because ir_build_field_ptr expects a pointer to the base thing.

Also you would need to extract the body of ir_analyze_instruction_field_ptr into something you can call from another "analyze" function -

Anyway go for it if it makes sense to you, but also this would be pretty easy for me to do on top of your work, so if it sounds like a chore, don't worry about it.

@andrewrk
Will be done after all TypeInfo generation code is completed.
EDIT: Working on it now after all

@andrewrk

I actually tried to implement the solution you suggested (all that was left was to get the type out of ir_analyze_instruction_field_ptr instead of getting the type of the type).
However I found out that ir_analyze_instruction_field_ptr prioritizes the tag when accessing a union, so having the same struct names as the tags was not an option.

I'm not sure if the current code is too hackish, it looks ok to me but I'm not acquainted to the compiler.

Ah, I hadn't considered that. Hm, that sounds a bit like a design flaw. Hmmmmmmm. Oh well. It's really cosmetic. We can solve that problem later. What's important is the functionality of @typeInfo working.

Perfect, thanks for this compile error. Don't forget to add a corresponding test in test/compile_errors.zig. Feel free to add it right at the top, and you can run those tests only with: bin/zig build --build-file ../build.zig test-compile-errors (and probably just kill it after it gets past your new one)

Just confirming your question from IRC: this is in fact the correct way to create a void instance 👍

I think if the type is void we just leave data.x_union.payload to be nullptr. But sounds like you ran into a problem with that?

...ah, I see, below, we need the result to have a pointee. Hmm. I think this solution is clever and correct, and let's go with it. In a future cleanup, maybe we just go ahead and create a void instance whenever we create a union const val for consistency. We could even cache a global instance of the void ConstExprValue because it's read only.

@andrewrk

Right, CodeGen::void_value could be a good place to have it.
As you said, I ran into trouble when I set the ref pointee to be nullptr, which is why I made the value this way.

unfortunate that we have these footguns here. (this problem exists elsewhere in ir.cpp, so you're not introducing a new problem). but maybe we could add some asserts like this?

assert(find_struct_type_field(int_info_type->data.x_type, buf_create_from_str("is_signed"))->src_index == 0);

so that we at least get asserts in debug builds if the code in codegen.cpp that writes builtin.zig is changed. and then in release mode we don't do the find.

let's add a zig_panic("TODO") for the ConstParentIdArray case - this will save future us trouble when we need to handle this case. same goes for other switch cases in this function.

why is that?

@andrewrk

Well, tbh we don't "need" to, I just think it's cleaner if the compiler gives us a const ref to the TypeInfo instance.

The user can then copy it if they need to.
It's probably just fine to return it by value too though, I don't know why it struck me as necessary in the first place :P

This is good as is, but just a note, this is going to become a top level export of builtin.zig after #661

these asserts are appreciated, and will for sure prevent bugs in the future 👍

This attention to detail is appreciated, but just so you know: the c++ compiler doesn't even pretend to try to free memory. We treat the entire OS's memory as one big ArenaAllocator that gets freed upon process exit.

The self hosted compiler has a higher standard though. Because it is meant to be used as a long running process that performs multiple compilations, it will need to get these details correct.