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

Fix and optimize visit_target usage #510

Merged
merged 6 commits into from
Jul 5, 2021
Merged

Fix and optimize visit_target usage #510

merged 6 commits into from
Jul 5, 2021

Conversation

Kijewski
Copy link
Collaborator

@Kijewski Kijewski commented Jul 1, 2021

There was a bit of code duplication in generator.rs with respect to the output of targets.

Also there was a bug which caused broken code for

{% for val in range %}{% set val = "anything" %}{% endfor %}

which tried to write to val instead of shadowing it.

Kijewski added 3 commits July 2, 2021 16:40
By now only non-nested tuples are accepted by the parser, but this will
change. This change makes visit_target() call itself for items in a
tuple. So enable the function to call itself, I needed to fix the
lifetime annotation, because the references inside a Target instance may
outlife a reference to instance itself.
Copy link
Collaborator

@djc djc left a comment

Choose a reason for hiding this comment

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

Wow, thanks for taking on this much-needed refactoring. Some fairly minor comments.

}
Target::Tuple(targets) => {
let shadowed = targets.iter().any(|name| {
let (shadowed, _) = self.shadows_or_declares_variable(&Target::Name(name));
Copy link
Collaborator

Choose a reason for hiding this comment

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

self.shadows_or_declares_variable(&Target::Name(name)).0?

Comment on lines 831 to 825
if shadowed {
(true, true)
} else {
(false, true)
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

(shadowed, true)

Comment on lines 852 to 855
if shadowed {
// Need to flush the buffer if the variable is being shadowed,
// to ensure the old variable is used.
self.write_buf_writable(buf)?;
}
if declared {
buf.write("let ");
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Would it make sense to inline these effects into shadows_or_declares_variable() (I suppose it would need yet another name)? Splitting it this way doesn't make for a great abstraction.

Comment on lines 1522 to 1521
if initialized {
self.locals.insert(name, LocalMeta::initialized());
} else {
self.locals.insert_with_default(name);
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Here's an example where I'd probably write a match instead. What do you think?

@Kijewski
Copy link
Collaborator Author

Kijewski commented Jul 2, 2021

I addressed you comments.

Actually I'm not sure if I like matching bools. I'm quite new to rust and as a Python / C++ programmer it just feels wrong. You'd get publicly stoned if you shared C++ code that contains switch (cond) { case true: … :)

@djc
Copy link
Collaborator

djc commented Jul 5, 2021

Actually I'm not sure if I like matching bools. I'm quite new to rust and as a Python / C++ programmer it just feels wrong.

Can you articulate what you dislike about them?

@djc djc merged commit 20a5f7a into rinja-rs:main Jul 5, 2021
@Kijewski Kijewski deleted the pr-var-initialization-in-loop branch July 5, 2021 10:22
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.

2 participants