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

std.target | Remove comment referencing closed proposal #16597

Merged
merged 1 commit into from
Jul 29, 2023
Merged

std.target | Remove comment referencing closed proposal #16597

merged 1 commit into from
Jul 29, 2023

Conversation

zraineri
Copy link
Contributor

Removes a comment referencing #425 which has been closed

Removes a comment referencing #425 which has been closed
@andrewrk andrewrk merged commit 423c122 into ziglang:master Jul 29, 2023
@mlugg
Copy link
Member

mlugg commented Jul 29, 2023

Might it be reasonable to mark those functions as inline? That would have the effect the comment was going for, and those functions are all pretty trivial so it should have no noticeable effect on compilation speed.

@andrewrk
Copy link
Member

I was thinking the same thing

@mlugg
Copy link
Member

mlugg commented Jul 29, 2023

I'll spin up a PR in a moment

@zraineri zraineri deleted the patch-2 branch July 31, 2023 01:47
mlugg added a commit to mlugg/zig that referenced this pull request Aug 3, 2023
This was discussed in ziglang#16597. It makes sense for most of the functions
in this file to be marked inline: many are simple helper functions so
inlining is likely a strict win, and having the return values be
comptime-known may improve userspace code in some cases by preventing it
from unintentionally checking properties of the target at runtime.

This changeset is somewhat conservative: the functions marked inline are
generally returning booleans or simple integers, and many are simple
one-line checks.
andrewrk pushed a commit that referenced this pull request Aug 3, 2023
This was discussed in #16597. It makes sense for most of the functions
in this file to be marked inline: many are simple helper functions so
inlining is likely a strict win, and having the return values be
comptime-known may improve userspace code in some cases by preventing it
from unintentionally checking properties of the target at runtime.

This changeset is somewhat conservative: the functions marked inline are
generally returning booleans or simple integers, and many are simple
one-line checks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants