Skip to content

A train of small patches #4443

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

Merged
merged 5 commits into from
Feb 13, 2020
Merged

A train of small patches #4443

merged 5 commits into from
Feb 13, 2020

Conversation

LemonBoy
Copy link
Contributor

I've included @data-man patch as I needed it to write some test cases

The g->module is long gone when codegen_link is called.
@LemonBoy LemonBoy closed this Feb 13, 2020
@LemonBoy LemonBoy reopened this Feb 13, 2020
@LemonBoy
Copy link
Contributor Author

The patch that affects the for loop is trickier than it looks.

At the moment all the payload-extracting operations (if (x) |y|, while (x) |y|, for (x) |y|) alias the y location to the payload location with a simple trick: an "empty" (with no backing memory) variable named y is created and its allocation pointer is simply set to whatever the unwrapped/iteration address is.
Now this behavior is source of several nasty bugs (#2915) by itself, but the implementation is also flawed (#4361) as variables cannot reside at address zero!
I think the first step to properly solve this problem is to decide what the "right" behavior is and then either amend all the cases outlined above or implement some workaround to handle the allowzero case.

My vote is for making the unwrap operation perform a copy as it's more in-line with how const x = y behaves (and I see many other people thought the same). If the user wants to avoid the copy and/or have a mutable reference they can simply prepend a * to the variable name and reap all the benefits without having to stop and think too much about how those constructs behave.

I'll drop that patch from this series so that we can discuss this problem without holding back the other good stuff.

@andrewrk
Copy link
Member

My vote is for making the unwrap operation perform a copy as it's more in-line with how const x = y behaves (and I see many other people thought the same). If the user wants to avoid the copy and/or have a mutable reference they can simply prepend a * to the variable name and reap all the benefits without having to stop and think too much about how those constructs behave.

I agree with this, this will be the path forward. Thanks

@andrewrk andrewrk merged commit 1675d4f into ziglang:master Feb 13, 2020
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