Adds gitignore for the build directory #3

bslatkin · 2014-06-21T04:48:22Z

No description provided.

Setup the scaffolding for the Python compiler. This CL includes the entry point, its initial configuration, and high level tasks such as the file read/write. All actual code generation is left for future CLs; simply throwing an UnsupportedOperationException for now. Unlike the JS Compiler, I don't think we'll need a separate, Google only, version. Instead the few Google specific configurations can be passed in at compile time (namely the runtime path and bidi directionality fn path). The compiled Python will be written to use those paths and all google specific dependencies can be loaded at runtime. ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=83032170

Related Design Doc: [] [] This CLs wrote the skeleton code and helper class for processing MsgNode. - PyFunctionExprBuilder: a helper class to output Python function code, it builds to a PyExpr and could be used recursively. - MsgFuncGenerator: the core class for MsgNode translation code implementation, it could return the function code either as a PyExpr or a PyStringExpr. Some issues to be reviewed: - overloading PyFunctionExprBuilder APIs to reduce manually creation of PyExprs. ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=86135265

1. map literals should only be interpreted as a record type if all the keys are string literals (the current check for this is insufficient, it just checks that all the keys are strings) 2. Check that all record literals only pass one instance of each key 3. Unions with UKNOWN should just be UKNOWN, 'unknown|string' should be equivalent to 'unknown' Item #3 required a fix in the CheckCallingParamTypesVisitor to allow protos to be bassed to unknown parameters in (otherwise) strict templates. I discussed this with talin offline and it appears that the reason to disallow passing protos to templates as unknown was to prevent users from passing protos to non-strict templates. So instead i implemented that check. This was refactored off of [] since this half of the cl is believed to be less risky. ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=91993285

@param

… what is going on. Basically, given a template like: {@param list :list<string>} {foreach $item in $list}...{/foreach} {let $foo : 'a' /} {$foo} I will generate code that stores both $list and $foo in a local variable. It happens to be the case that $foo and $item have non-overlapping scopes so I take advantage of this and store them both in local variable slot #3. This means that at various points slot 3 holds List or a soyValueProvider so ASM needs to know their least common super type in order to generate a valid stack map frame for slot #3. This is kind of unfortunate, because it should be possible to tell ASM that the first use of #3 doesn't overlap with the second usage. ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=97089362

…java_binary for invoking this functionality. Soon I will add support to af_soy_library for invoking this binary, but for now there is just a proof of concept that compiles and runs the integration tests. The biggest issues now are that 1. the runtime dependencies of the generated code are not well encapsulated 2. the runtime dependencies of the generated code still depend on the AST (due to bad build targets afaict) 3. there is nothing that will flag if the generated code is missing a runtime dependency (e.g. no strict_java_deps for the compiled jar). Some of these are known issues (especially #2) and I'm going to reach out to java-users/javac-team for advice on #3. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=107536995

…anitizedContent kinds. This addresses #1 and #3 in [] GITHUB_BREAKING_CHANGES=Map accesses with SanitizedContent keys besides TEXT will stop working. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=196679840

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

…is involves 1. making more comments LineCommentLeaf nodes 2. removing inlining of attribute values if the value contains comments (or is force) 3. creating leaves instead of finding the nearest appending point if the first or last element is a LineCommentLeaf. The optimization in #3 was nice, but it made the formatting idempotent since it changes the AST in a way that it would format differently a second time around. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=301222043

bslatkin and others added 4 commits June 20, 2014 21:46

Adds gitignore for the build directory

3efb48f

Upgrade to Guava 17

261a867

Ignore the wall

25f0f25

Silence the Guice injector warning

feaf2d4

eriktim mentioned this pull request Jul 4, 2014

getHackySoyFileSetFactory warning #5

Closed

bslatkin closed this Jul 21, 2014

mikesamuel mentioned this pull request Apr 17, 2014

Add Python support #1

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adds gitignore for the build directory #3

Adds gitignore for the build directory #3

bslatkin commented Jun 21, 2014

Adds gitignore for the build directory #3

Adds gitignore for the build directory #3

Conversation

bslatkin commented Jun 21, 2014