Skip to content

compiler includes internal indices in type and function names #24116

Open
@mlugg

Description

@mlugg

Zig Version

0.15.0-dev.762+3208c80f2

Steps to Reproduce and Observed Behavior

Declare a type in a non-trivial way and look at its name:

const S = blk: {
    break :blk struct {};
};
comptime {
    @compileLog(@typeName(S));
}
$ zig build-obj repro.zig
Compile Log Output:
@as(*const [19:0]u8, "repro.S__struct_213")

Or, instantiate a generic function and look at its name in the binary:

fn generic(comptime _: u32) void {}
export fn foo() void {
    generic(0);
}
$ zig build-obj repro.zig && nm repro.o | grep generic
0000000000000040 t repro.generic__anon_494

These numbers are indices into the compiler's InternPool.

Expected Behavior

The names ideally should not depend on details of compiler internals. We should aim to generate descriptive names.

If it turns out there isn't a good alternative way to generate unique names, then at the very least, these type names with random numbers in them shouldn't be printed in compile errors which mention the types. It would be relatively easy for us to give the type a different name when printing it.

#24115 tracks missing test coverage which was deleted because it depended on these names.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugObserved behavior contradicts documented or intended behaviorfrontendTokenization, parsing, AstGen, Sema, and Liveness.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions