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

Do not allow callconv, align, addrspace, or linksection to reference function arguments #22261

Closed
mlugg opened this issue Dec 17, 2024 · 0 comments · Fixed by #22264
Closed
Labels
accepted This proposal is planned. 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 17, 2024

Split out from #11834.

Allowing these things to reference previous parameters requires the compiler implementation to track all of these properties in more places, increasing memory consumption. It also requires the compiler to have a separate representation of these properties for functions vs other declarations.

Another implementation problem with callconv in particular, originally mentioned in #11834, is that status quo can lead to us finding out that a function should be inlined (due to having callconv(.@"inline")) after analyzing its arguments, which is too late -- we've already started creating a generic instantiation! (Admittedly, though, this problem still exists -- and likely always will exist -- for the case of a return type turning out to be comptime-only.)

There isn't much point in actually allowing this; you'd have to be deep in generic crazy land to be affected by this change, and if you really need it, you can wrap your whole function in a generic type. Therefore, this proposal is to disallow the bodies of callconv(...), align(...), addrspace(...), and linksection(...) on function bodies from referring back to function parameters.

@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. accepted This proposal is planned. labels Dec 17, 2024
@mlugg mlugg added this to the 0.14.0 milestone Dec 17, 2024
@mlugg mlugg closed this as completed in 7408679 Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted This proposal is planned. 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

Successfully merging a pull request may close this issue.

1 participant