Is there a doc page for the import("builtin") type/module?

[zigo]

btw: Zig has three distinct concepts involving the term “builtin”: builtin functions, the import("builtin") module, and the import("std").builtin module. While not a major issue, this overlap can be slightly confusing for learners new to Zig.

[Sze]

There is the --show-builtin option that allows you to look at the contents of import("builtin"):

How to check if Target supports various instructions, avx512f

You can access the current cpu from builtin.cpu const builtin = @import("builtin"); const cpu: std.Target.Cpu = builtin.cpu; _ = cpu.features; cpu.features is a list with all the features. Use zig build-exe --show-builtin or zig build-exe --show-builtin -target aarch64-linux-musl to view all the builtin declarations with values for the current target.

[Calder-Ty]

I agree the 3 “builtins” is confusing. I don’t think there is a way to view docs for import("builtin"), as that file is specific to the target machine (IIRC). But I have had success with zls and “go to definition” to view the file.

[vulpesx]

std.builtin is @import("builtin")

[tensorush]

That’s the confusing part – they are different:

• @import("builtin") is a module with current compilation details that is automatically generated and exposed to the user code. Should probably be called smth like info.

• @import("std").builtin is a standard library namespace with type definitions that are used by the compiler backends as well as exposed to the user code. Should probably be called smth like impl or types.

[vulpesx]

clearly the code fairies added a .zig to the import when i wasnt looking to spite me, no other explanation

[matklad]

Oh, dear, I remember being massively confused about this as well. Yeah, it feels like it’s best to move std.builtin.Type and friends elsewhere. std.zig.Type reads nice, though it muddies the water as to what’s unstable and what’s very unstable in std.m