Skip to content

Bugfix #778: Flag for entry into for loop after range has been processed #795

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
Dec 16, 2023

Conversation

fknauf
Copy link
Contributor

@fknauf fknauf commented Nov 1, 2023

Fixes #778, and it's possibly relevant for #432.

I ran the regression tests and spotted no differences in output. I also have a bash script now to run the tests on a Linux machine, should I put that in here as well?

Copy link
Contributor

@JohelEGP JohelEGP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you.
The approach looks correct to me.
Can you add these tests for confirmation?

issue_778: (args) = {
   for :() args$;() do (i) _ = i;
   for :(x) x;(args) do (j) _ = j;
   for :(x) x;(args) next _ = :() args$;() do (k) _ = k;
   for :(x) x;(args) next _ = :(x) x;(args) do (l) _ = l;
}

@fknauf
Copy link
Contributor Author

fknauf commented Dec 13, 2023

I added the tests. The output was compileable and looked reasonable to me. Then I merged the new state of the main branch and ran the tests again. All tests are green, so it seems to work and not break anything.

@JohelEGP
Copy link
Contributor

Thank you for this.

This is definitely the right approach.
If things are not marked right before they are needed, you end up needing to use stacks.
That's because function expressions are very general,
so in the most extreme case you can have a for loop before an outer's for loop do.
Without stacks, that would erase any state before the outer's for loop do.
Marking things right before is simpler than stacks and correct by construction.

@fknauf
Copy link
Contributor Author

fknauf commented Dec 13, 2023

I'm not 100% sure I agree that flags like this one are the correct way to handle parsing context like this, but it seemed like the least invasive way to handle it. In a new design I'd maybe consider encoding information like this in the parse tree so that the safety of the expression becomes an S-attribute.

@hsutter
Copy link
Owner

hsutter commented Dec 15, 2023

(Catching up with PRs, sorry for the delay)

Thanks for your pull request! It looks like this may be your first contribution to cppfront. I've sent the Contributor License Agreement (CLA) to your email, and once it's signed I can look at your pull request. Thanks again for your contribution.

For better or worse, I've been using `_tag` types instead of adding to the `start`/`end` names, so just staying consistent for now.
@hsutter
Copy link
Owner

hsutter commented Dec 16, 2023

Thanks! I just made a minor style tweak to follow the style I was already using for such so-far-very-occasional extra information.

@hsutter hsutter merged commit faf57af into hsutter:main Dec 16, 2023
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.

[BUG] Passing lambda to function call of for loop causes incorrect uninitialized variable error
3 participants