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

Improve list iteration #2

Open
segabor opened this issue Oct 29, 2018 · 0 comments
Open

Improve list iteration #2

segabor opened this issue Oct 29, 2018 · 0 comments
Assignees

Comments

@segabor
Copy link
Owner

segabor commented Oct 29, 2018

The following list iteration

{@param names: list<string>}
{for $name in $names}
...
{/for}

compiles to

if let nameList30 = data["names"] {
  for (nameIndex30, nameData30) in nameList30.enumerated() {
  ...
  }
}

which is broken. A possible manual fix is

if let nameList30 = data["names"] as? [String]

Compiler should infer list type from parameter declaration.

@segabor segabor self-assigned this Oct 29, 2018
@segabor segabor added the bug label Oct 29, 2018
segabor pushed a commit that referenced this issue Mar 7, 2019
For soy, parsing proto descriptors is a complex multi stage process.
1. parse the binary protos -> FileDescriptorSet protos in memory
2. resolve all the FileDescriptorSet protos against each other
3. index all the messages, enums and extensions to populate the type registry

Prior to this CL we were simply doing #1, now we cache the result of #2 as well.  This relies on the new SoyInputCache.declaredDependency method to inform the cache how all the objects depend on each other.

I explored caching step 3 as well, but this would require creating an entirely new way to construct a SoyTypeRegistry which didn't seem worth it.  Instead i just made the indexing code a little more efficient (which should help even in non-worker mode)

For worker mode this saves about 15% of the time of a soy compile.

GITHUB_BREAKING_CHANGES=none

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=227918474
segabor pushed a commit that referenced this issue Jun 18, 2019
The addition of @State and default parameters has stretched TemplateVariableManager past its breaking point.  It currently has 3 responsibilities

1. creating field definitions
2. managing local variable lifetimes
3. generating save/restore logic

The issue is that #1 is for the whole class, #2 is for a single method and #3 is for the render() method.

This conflation was fine when the render() method was the only method with any non-trivial logic, but now that we have default parameters and @State initializers we have a desire to generate code for arbitrary soy expressions in the constructor or static initializers.  Right now this is just corrupting some debugging metadata, but future changes will cause more issues.

This requires us to break up these responsibilities.  This is step 1.  next will be to extract a mechanism to create temporary variables that is detatched from save/restore state solution.

GITHUB_BREAKING_CHANGES=none

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=249533688
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant