Fix build.xml after package rename of custom Ant task #2

tbroyer · 2014-05-08T15:32:43Z

No description provided.

Ubehebe · 2014-10-10T16:11:17Z

This is fixed on master by 31fd952.

With some renewed interested, work is back underway for the Soy to Python compiler. This CL implements the sanitization generator for Python, as well as runs it to pull an update to normalized URIs. The generator extends AbstractGenerateSoyEscapingDirectiveCode and implements Python syntax where needed. ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=81604798

Related Design Doc: [] [] This CLs added support for MsgFallBackGroupNode, the root of all message nodes. Right now, it only supports MsgNode with RawTextNode as its child. It handles a possible fallback message and deligate the actual PyExpr generation work down to MsgNode in GenPyExprVisitor. Some issues to be reviewed: - I use SoyPySrcOptions to hold static method name information we will use in Python. This goes with [] ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=85184557

…don't handle them. This approach appears to be completely consistent with jssrc and mostly consistent with tofu. Tofu uses the special 'undefined' soy value in this case which prevents printing undefined values, we just use normal java null in this case which is more consistent with jssrc. ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=97162152

…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

In soy msg tags, certain nodes like {call} {print} and html tags are wrapped in Placeholder nodes since they will be turned into message placeholders. This logic currently happens in the javacc parsing. This cl moves the logic for turning placeholders into a dedicated pass. This has two benefits 1. slight simplification of the parser (now msgs can just be TemplateBlocks) 2. will enable moving the the parsing of html tags to the HtmlRewritePass (and the eventual removal of the custom lexical state for msgs). #2 requires some explanation. consider this msg {msg desc="foo"} Peruse our <a href="{$menuUrl}>menu</a> {/msg} given that html tag parsing happens in the javacc, the html tag will get turned into a placeholder. However, if we remove the ability to parse html tags from the parser, then the print node '{$menuUrl}' will get parsed as a placeholder which is not correct. So instead placeholder assignment is be delayed to a later pass which will allow us to (in a followup) move tag parsing into the html rewrite pass. Also, move the 'verifyphname' pass logic into the new pass since it uses very similar logic. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=154983159

… loop we would inject multiple (3) nonces This is due to two different bugs 1. when analyzing foreach loops we generate two copies of all the SlicedRawTextNodes from the loop body 2. when duplicates were observed by the nonce injection pass a bug would cause us to inject the nonce multiple times. For #1 i am simply deduping the slices, this code shouldn't survive long (to be replaced by ContentSecurityPolicyNonceInjectionPass) at which point all the SlicedRawTextNode code can be removed. For #2 it is a simple enough fix in the grouping logic Also delete some dead and complex code in SlicedRawTextNode.. to make it clearer ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=157067167

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

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

Fix build.xml after package rename of custom Ant task

831da89

Ubehebe closed this Oct 10, 2014

tbroyer deleted the fix-ant branch October 10, 2014 16:49

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

Fix build.xml after package rename of custom Ant task #2

Fix build.xml after package rename of custom Ant task #2

tbroyer commented May 8, 2014

Ubehebe commented Oct 10, 2014

Fix build.xml after package rename of custom Ant task #2

Fix build.xml after package rename of custom Ant task #2

Conversation

tbroyer commented May 8, 2014

Ubehebe commented Oct 10, 2014