Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove redundant cpu/os/abi/object_format declarations from @import("builtin") #22267

Open
mlugg opened this issue Dec 19, 2024 · 0 comments
Open
Labels
breaking Implementing this issue could cause existing code to no longer compile or have different behavior. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@mlugg
Copy link
Member

mlugg commented Dec 19, 2024

Right now, details of the compilation target can be accessed through @import("builtin") in multiple ways:

  • builtin.target.cpu and builtin.cpu
  • builtin.target.os and builtin.os
  • builtin.target.abi and builtin.abi
  • builtin.target.ofmt and builtin.object_format

These are guaranteed to always be equivalent -- target is actually just defined like this:

pub const target: std.Target = .{
    .cpu = cpu,
    .os = os,
    .abi = abi,
    .ofmt = object_format,
    .dynamic_linker = .init("/lib64/ld-linux-x86-64.so.2"), // this line varies per target
};

As such, having both around is entirely redundant, and has no benefit. This is a violation of "Only one obvious way to do things".

Since builtin.target bundles these values together in a logical way, it is the more useful declaration (it is easier and more concise to get a field from target than it is to reconstruct target from its fields). Therefore, this is a proposal to remove the following declarations from the generated builtin.zig source code:

  • cpu
  • os
  • abi
  • object_format

These declarations should be marked as deprecated for one release cycle, and then entirely removed in a following one. I expect that the current definitions of cpu, os, abi, and object_format will just be inlined into the definition of target.

@mlugg mlugg added breaking Implementing this issue could cause existing code to no longer compile or have different behavior. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. labels Dec 19, 2024
@mlugg mlugg added this to the 0.15.0 milestone Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking Implementing this issue could cause existing code to no longer compile or have different behavior. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

1 participant